MCP 是什麼？AI 從會聊天進化到會做事的關鍵協定，一篇看懂模型上下文協定

AI INFRASTRUCTURE · 2026

▲ MCP 把 AI 從「會聊天」推到「會做事」——中間那顆晶片就是協定本身，旁邊插滿的全是它能伸手碰到的工具。

AI 已經會寫文章、會改設計、會做研究報告好一陣子了。但你有沒有發現一件事——它所有事都還是在「告訴你怎麼做」，而不是「直接幫你做」。

你要它訂張高鐵票？沒辦法。你要它把這次設計稿的所有圖層名稱統一？沒辦法。你要它把 Notion 裡某個 database 的內容整理成週報寄出去？也沒辦法。它什麼都知道，但它的手被綁住。

鬆開那條繩子的，就是 MCP。

這篇我用設計師看得懂的方式拆給你看：MCP 是什麼、它怎麼運作、為什麼整個矽谷都在跟進、設計工作流可以怎麼接，還有它沒人在講的限制。

CHAPTER 01 · WHAT IS IT

MCP 是 AI 世界的 USB-C，一根線通到底

MCP 全名 Model Context Protocol，中文直翻是「模型上下文協定」，但這名字翻得不太人話。我自己會用一個比喻——它是「AI 的 USB-C 規格書」。

USB-C 之前的世界你應該記得，每個品牌一條線、每台筆電一個孔，出門包包要塞五條線才能應付一天。USB-C 出來之後，一條線通到底，手機平板筆電耳機全部插同一個孔。MCP 在 AI 世界做的事情一模一樣。

在 MCP 之前，每一個 AI 想接一個外部工具，工程師都得手刻一個 connector。Claude 要接 Notion，工程師寫一套。ChatGPT 要接 Notion，工程師再寫一套。Cursor 要接 GitHub，工程師再寫一套。N 個 AI 應用乘以 M 個工具，就是 N×M 個 connector 要寫，整個業界在做重複勞動。

MCP 把這件事翻過來。每個工具實作一次 MCP server，每個 AI 應用實作一次 MCP client，剩下的全部自動互通。寫一次，連所有人。

▲ MCP 官方品牌標誌。捐贈給 Linux Foundation 之後，這個 logo 成了跨產業共同遵守的標準符號。

CHAPTER 02 · WHY IT MATTERS

為什麼整個矽谷搶著支援 MCP

Anthropic 提出一個新協定，本來是公司行為。怪的是接下來這一年——OpenAI 把它接進 Agent SDK，Google DeepMind 跟進，AWS、Microsoft、Block、Apollo 一個個跳上船。連 OpenAI 這種跟 Anthropic 直接對打的公司都採用了。

原因很簡單——這件事誰先放下個人面子，誰先得到整個生態系。

你想想 HTML 的歷史。當年 HTML 也不是哪家公司發明來壟斷的，是一個開放規範，讓所有瀏覽器、所有網站可以互通。然後整個 Web 起來了。HTML 不是某個產品，是底層的「水電瓦斯」，所有後來的東西都建在它之上。

MCP 走的就是這條路。Anthropic 自己也很清楚——2025 年 12 月，他們乾脆把整個協定捐給了新成立的 Agentic AI Foundation，掛在 Linux Foundation 底下。這個動作擺明告訴所有人——這玩意不是我的，是大家的，請放心用。

捐出去那一刻，MCP 從「Anthropic 的協定」正式變成「業界標準」。Block、OpenAI、AWS、Google、Microsoft 全都掛名創始成員。

TIMELINE · MCP 17 個月成為產業標準

CHAPTER 03 · HOW IT WORKS

MCP 的三個角色，看懂這張圖就夠了

MCP 的架構其實意外簡單。整個系統只有三個角色，學一次受用一輩子。

整個流程像這樣——你在 Claude Desktop 裡輸入「幫我查 Notion 裡關於 Q3 的所有筆記，整理成 markdown」，這個請求送到 LLM。LLM 知道自己有 Notion 這個工具可以用，就透過 MCP client 對 Notion MCP server 發出 search 請求。Server 回傳結果，client 翻譯給 LLM，LLM 整理成 markdown 回你。

你看到的是「Claude 幫我整理筆記」這個結果。底下其實是三個角色在合作。

這個架構的精妙在於——LLM 不需要知道 Notion 的 API 長什麼樣，Notion 也不需要知道 LLM 怎麼想，雙方都只要對 MCP 規範負責。協定當中間人。

OFFICIAL VIDEO · 為什麼 Anthropic 把 MCP 捐出去

這支是 MCP 共同創造者 David Soria Parra 親自談「為什麼我們建造、然後捐贈了 MCP」。看他講第一手脈絡，比看任何二手分析文都來得透徹。

CHAPTER 04 · IN PRACTICE

設計師的工作流接 MCP，可以解鎖什麼

這段是設計師最該看的。MCP 不是工程師的玩具，它讓 AI 真的能伸手碰到你每天在用的工具。

場景一——Figma 設計檔變成 AI 看得懂的東西

Figma 官方已經有 MCP server。接上之後，你可以跟 Claude 說「打開我 Figma 裡的這個檔案，找出所有沒命名的圖層，幫我用我的命名規則重新命名一輪」。它真的會去開檔、掃圖層、改名稱。

更進一步的玩法是——AI 直接看你的設計稿，回給你「這個 button 的 padding 跟你 design system 裡定義的不一致」。它不是猜的，是去 query 你的 component library 對照出來的。

場景二——Notion 工作筆記變成設計知識庫

我自己常用的工作流——把品牌規範、case study、客戶 onboarding 流程全部寫在 Notion，然後 Claude 透過 MCP 直接 query 這些內容。下一次接案要寫提案，AI 不是憑空生，是基於我自己過去寫過的東西生。

這個威力在於——AI 終於知道「你是誰、你怎麼做事」。它的回答帶著你的個人風格，不是通用 ChatGPT 那種「正確但空泛」的東西。

場景三——自己的內容管理後台變成 AI 工作站

進階一點的話，你可以把自己的部落格後台、設計素材庫、課程平台都接成 MCP server。我自己這邊 RAR 設計攻略的後端、Ghost 部落格、Notion 知識庫，現在都是 MCP 介面。要發文、排版、上素材，AI 都能直接動手。

你想像一下——你早上想到一個主題，跟 AI 講一下大綱、丟兩張參考圖，下午有一篇排版好、配圖到位、SEO 結構完整的文章就上線了。中間沒有複製貼上、沒有檔案上傳、沒有來回切視窗。這就是 MCP 真正打開的工作流。

CHAPTER 05 · LIMITS

沒人想講的 MCP 真實限制

寫到這裡，這篇文章已經跟其他介紹 MCP 的文章長得差不多。但下面這段才是我覺得設計師真的要知道的——MCP 不是萬靈丹，它有幾個現實問題。

問題一——資安風險真實存在

2026 年 4 月 Ox Security 揭露 MCP STDIO interface 的設計缺陷——傳入惡意指令時，即使收到錯誤回傳，指令還是會被執行。Anthropic 的回應是「這是設計如此，sanitization 由 developer 自己負責」。社群正在持續討論。

對設計師來說的實務含意——不要隨便裝來路不明的 MCP server。社群上現在有上萬個 server，但其中很多是個人專案，沒有經過稽核。要裝就裝官方的（Anthropic、Notion、Figma 自己出的），或是 GitHub 上 stars 數高、有持續維護的。

問題二——context 暴漲是個大坑

你連上越多 MCP server，AI 的 context window 就被工具定義吃越多。一個複雜的 server 可能有 50 個 tool definition，5 個 server 加起來 250 個。光是「告訴 AI 你有哪些工具」就把 token 吃掉一大塊，留給實際對話的空間就變少。

Anthropic 自己有發過一篇〈Code execution with MCP〉的工程文章，提出「不要把所有 tool 都載入 context」的改進方向——讓 AI 自己去搜尋需要的 tool 再載入。但這個還是進階用法，一般使用者目前最好的策略就是「需要哪幾個 server 才開，不需要就關」。

問題三——多媒體還在路上

到 2026 年 5 月為止，MCP 主要還是處理文字跟結構化資料。圖片、影片、音訊的標準傳輸正在規範當中（MCP Apps / SEP-1865 是其中一個方向），但還沒到「隨便接都能用」的程度。如果你的工作流是大量視覺檔案，目前還是要靠 Host 端自己處理。

SUBSCRIPTION · AIWAKEN

AI 覺醒設計應用攻略

AI 工具每週都在更新，我幫你過濾雜訊，只整理對設計師真正有用的應用。

✦ AI 工具實測與工作流

✦ 設計師角度 Prompt 技巧

✦ 每週 AI × 設計新知

了解訂閱方案 →

CHAPTER 06 · TAKEAWAYS

真正的 AI 時代，從手被鬆開的那刻開始

寫了快十年設計，我對「工具改變設計」這件事一直保持某種距離感。Photoshop 換到 Sketch、Sketch 換到 Figma、Figma 加上 AI——每一次都被講成革命，但實際工作流改的幅度沒有想像中大。

MCP 不一樣。它改的不是工具，是工具跟工具之間的縫隙。

設計師每天有多少時間是花在「複製貼上、切視窗、找檔案、傳檔案、改格式」上？我估計是一半以上。這些縫隙不會出現在你的 portfolio 裡，但它真的存在，而且每天都在偷你的時間。

MCP 在做的事情，就是把這些縫隙填掉。讓 AI 可以一條龍從「看到問題」直接走到「動手解決」，不用你當人肉中介。

這件事的長遠影響是——未來會做設計的人不會少，但會被分成兩種人。一種人還在用滑鼠手動拖元件、手動切視窗、手動整理素材；另一種人已經把工作流接好 MCP，他只負責「下決定」，剩下交給協定處理。

兩種人單位時間產出會差幾倍，我不敢算。但如果你還沒開始研究 MCP，今年是最後的安全期。

常見問題

Q——MCP 跟 OpenAI 的 Function Calling 有什麼不一樣？

Function Calling 是「單一 AI 應用內」呼叫工具的機制，每個應用要自己定義一套規範。MCP 是「跨 AI 應用的標準」，工具寫一次所有 AI 都能用。簡單講——Function Calling 是私有道路，MCP 是公共高速公路。OpenAI 自己也已經把 MCP 接進 Agent SDK，兩者其實是互補的。

Q——一般使用者要怎麼開始用 MCP？

最簡單的方式是用 Claude Desktop 或 Claude.ai，在設定裡開啟 Connectors 功能，從目錄選你要的工具（Notion、Google Drive、Gmail、Calendar 等）授權連接，整個過程不需要寫程式。Cursor、Zed 也有類似的內建 MCP 設定介面。

Q——MCP server 安全嗎？我該擔心隱私問題嗎？

協定本身設計上是要求 user consent 的，每次 AI 呼叫工具前 Host 應該要徵詢使用者同意。但如同前面提到的，2026 年 4 月有研究者揭露 STDIO interface 的設計缺陷。實務建議是——只裝官方或大廠出的 MCP server、敏感資料不要連上未稽核的 server、定期檢查授權清單。

Q——非工程師可以自己做 MCP server 嗎？

可以。FastMCP 這類 Python 框架已經把門檻降到很低，加上現在用 Claude Code 之類的 AI 開發工具，描述你要的功能就能生出一個 prototype。當然要做出 production-grade 的 server 還是需要工程能力，但「給自己用」的層級確實普通技術愛好者就做得到。

Q——MCP 會被取代嗎？要不要等等再學？

短中期不會。MCP 已經被 OpenAI、Google、AWS、Microsoft 同時採用，又捐給 Linux Foundation 變成中立標準，這種程度的產業共識很少見。它更可能的演進方向是「往上長」——多媒體支援、code execution、安全機制強化——而不是被取代。現在學完全來得及，等下去機會成本反而比較大。

Q——MCP 跟 Agent、AI 代理是什麼關係？

AI Agent（代理）是「會自己規畫、執行任務」的 AI 系統。MCP 是 Agent 用來「碰到外部世界」的標準介面。可以這樣理解——Agent 是大腦、MCP 是神經系統、外部工具是手腳。要做出真的能動手的 AI Agent，MCP 幾乎是必經之路。

Q——目前哪些設計工具有官方 MCP server？

到 2026 年 5 月為止，Figma、Notion、Linear、Slack、GitHub、Google Drive、Asana 都有官方或半官方的 MCP server。Adobe 還沒有官方版本（但社群有非官方實作），Canva 也還沒進場。預期接下來一年內主流設計工具都會跟上。

FURTHER READING · 延伸資源

· Anthropic 官方 MCP 公告——一手脈絡，懶得讀別人解讀就讀這個
· modelcontextprotocol.io——官方規範文件、SDK、示範 server 全在這
· GitHub Model Context Protocol——官方 repo，看程式碼學最快
· Claude Cowork 介紹——Anthropic 把 MCP 包裝成消費者產品的代表作
· Claude MCP Connectors 完整解析——Claude 內建 MCP 連接器的設定教學
· Managed Agents 完整介紹——MCP 之上的下一層抽象