能寫扎實的程式碼、能一口氣讀完落落長的合約，這種事對現在的 AI 早就不稀奇。你可能已經讓 Claude 或 ChatGPT 幫你整理過會議紀錄、抓過程式的錯，用起來得心應手。奇怪的是，這麼聰明的模型，卻連你自己電腦裡的一份試算表、公司內部資料庫的一張報表都碰不到，得靠你自己一段一段複製貼上，才能餵給它看。
問題顯然不在模型不夠聰明。真正卡住的地方，是 AI 跟外部世界之間，始終沒有一套大家都認得的共通語言，每換一個工具、每換一家 AI，連接的方式就得重新摸索一遍。Model Context Protocol（MCP，模型上下文協定） 要補的正是這個洞，讓 AI 模型能用同一套規格，直接連上你電腦裡的檔案、公司的資料庫、甚至外部服務，不用再靠人工搬運。這也是為什麼談到 AI 怎麼真的「動手做事」，MCP 是什麼協定這個問題近來被問得越來越多。
先從 MCP 出現之前，開發者實際上怎麼卡關講起，再一路拆到它怎麼解決、又帶來什麼新風險。
每接一個新工具，開發者就得重寫一次規則
在 MCP 出現以前，想讓一個 AI 模型接上一項外部工具或資料來源，開發者得為那個特定組合另外寫一套對接程式；換一家 AI 供應商，前面接好的東西幾乎得整套重寫。這不是誇張的說法，而是不少團隊實際踩過的坑。
假設一家中小企業想讓 AI 助理同時查詢內部知識庫與客戶資料表，為了接不同的 AI 模型、搭配不同的工具組合，得各自寫一套串接邏輯；工具一多、模型一換，工程量就跟著往上跳，而且往往不是線性增加，是成倍膨脹。業界把這種困境稱作「N×M 問題」。N 個 AI 模型乘上 M 項工具，整合點的數量會隨著兩邊同時成長，很快就膨脹到難以維護的地步。
具體來說，這種做法會付出三種代價。第一、重複開發：同樣的整合邏輯，換一個模型或換一項工具就得重新寫一次，前面的工夫幾乎歸零。第二、維護成本跟著往上疊：任一邊的規格一改版，原本接好的連線就可能失效，團隊得不斷回頭修補。第三、實作品質不一致：不同組合各自土法煉鋼，同樣一件事在不同整合裡做法不一樣，使用者用起來的體驗也跟著時好時壞。
其實在 MCP 之前，「function calling（工具呼叫）」這個功能本身早就存在，多數主流模型都支援讓 AI 判斷該呼叫哪個工具、帶什麼參數。真正缺的不是這個機制，而是一套共通規格，每家供應商都自訂一套呼叫格式，同一支工具想接兩家不同的模型，還是得各寫一份對接邏輯。
要解決的不是「AI 會不會用工具」，而是「這些工具跟資料，能不能用同一套語言接上」。這正是 MCP 要回答的問題。
MCP 是什麼？一句話看懂它解決的整合難題
Model Context Protocol，中文譯作模型上下文協定，就是文章一開始提到的 MCP。它是 Anthropic 於 2024 年 11 月推出的一套開放標準，讓 AI 模型能用同一套規格，連到外部的資料來源、工具與工作流程，不必為每個工具重新開發一次串接邏輯。
一個好懂的比喻是，MCP 之於 AI，有點像通用接口之於各種電子裝置。以前每一種裝置幾乎都有自己專屬的傳輸線，充電、傳資料都得配對應的接頭；後來有了通用接口，不管哪一種裝置，插上去就能直接用，不用再為每一種裝置各自備一條線。MCP 對 AI 模型做的正是同一件事，工具與資料來源這邊做好一次，任何支援 MCP 的模型都能直接接上。
這裡有兩件事值得特別說清楚。第一、MCP 從一開始就設計成開放標準，不是 Claude 或 Anthropic 自家的專屬功能，後面會看到，連 Anthropic 在市場上的競爭對手都陸續支援它。第二、MCP 本身不是「AI Agent（代理人）框架」，不負責幫模型做決策或規劃任務；它只負責把工具和資料接上給模型用，至於模型要不要呼叫、先呼叫哪一個、怎麼串成一套多步驟的任務，屬於 AI 應用本身的事，這篇不深入談。
先弄懂協定裡有哪些角色在互動，才看得懂這件事實際上是怎麼運作的。
認識 MCP 的三個角色：Host、Client、Server
要看懂 MCP 怎麼運作，得先弄清楚它裡面在跑的三個角色：Host（主應用程式）、Client（用戶端）、Server（伺服端）。Host 是你實際在互動的那個應用程式，像是 Claude Desktop，或是任何支援 MCP 的整合開發環境；Client 內建在 Host 裡面，負責跟某一個 Server 維持一對一的專屬連線，你平常看不到它，但它一直在背後跑。Server 則是真正提供某項工具或資料存取能力的服務端，例如專門負責讀寫某個資料庫、或串接某個雲端服務的那支程式。
這三者之間，靠 JSON-RPC 2.0 這套通訊格式交換訊息，而且分成兩種傳輸方式，看伺服端跑在哪裡而定。如果 Server 是在你自己的電腦上執行，通常用 stdio（標準輸入輸出），直接透過本機的程式輸出入來傳訊息，效能最好，也沒有網路傳輸的額外負擔。如果 Server 是遠端的服務，則走 HTTP 為主，搭配 Server-Sent Events（SSE）做串流回應，並支援標準的身分驗證方式。
Host、Client、Server 各自的分工
一個 Host 可以同時管理好幾個 Client，但每個 Client 只對應一個 Server，而且不同的 Server 彼此互不知道對方存在，各自獨立運作，不會互相干擾。
官方文件常舉一個例子讓這層分工更具體。一個負責資料庫的 MCP Server，可以同時提供三種東西：查詢資料庫的工具、描述資料庫欄位結構的資源，以及一組示範怎麼下查詢指令的提示模板。
一次工具呼叫，怎麼一步步跑完？
拿「使用者問 AI 今天某個地方天氣如何」這個常見情境，來看協定層面實際怎麼跑完一輪。
- 連線一建立，Client 會先問 Server「你有哪些工具可以用」，對應的方法叫 tools/list；Server 收到後，回傳一份工具清單，連同每個工具需要哪些參數。
- 使用者下了指令，AI 判斷這個請求需要外部資訊，從清單裡選出該呼叫哪一個工具。
- 多數 Host 這時候會先跳出一則授權提示，等你按下同意，才會真的去呼叫外部工具，這一步業界稱作 human-in-the-loop（人在迴路中），目的是避免 AI 未經同意就擅自對外部系統做出動作。
- 你同意之後，Client 才會發出真正的執行請求，對應的方法叫 tools/call，並帶上剛才判斷出來的參數。
- Server 實際執行這個請求，把結果包成標準格式回傳。
- AI 把回傳的結果整合進最終的回覆，呈現給你看。
這裡只講協定怎麼跑完一輪；AI 內部怎麼拆解、規劃更複雜的多步驟任務，屬於 Agent（代理人）本身的運作範疇，不在這篇的討論範圍。看懂這套角色分工怎麼跑之後，再回頭看最前面提到的整合困境，才知道 MCP 具體是怎麼把它解決掉的。
MCP 把整合從 N×M 降到 N+M
前面鋪陳的整合困境，MCP 用一個簡單邏輯正面回應。工具端與 AI 應用端各自只要把 MCP 規格實作一次，任何支援 MCP 的 AI 就能呼叫任何有 MCP Server 的工具。整合的總數，因此從「N 個模型乘上 M 項工具」，降成「N 個模型加上 M 項工具」。
這個差距，數字一多就會拉得很開。假設有五種主流 AI 模型、二十項常用工具，乘法邏輯下要接的組合是一百組；換成加法邏輯，只剩二十五個接口要顧。工具與模型的數量只要持續往上加，乘法跟加法的落差會越拉越大，原本得靠人力一組一組硬接的工程量，就這樣被壓縮下來。
這套解法對三種角色各有實際好處。對開發者而言，重複開發與後續維護的力氣省下來，不用每換一個對象就重寫一次邏輯。對 AI 應用來說，能更快接上完整的外部工具生態，不必自己一個一個談整合。對使用者而言，拿到的體驗是 AI 能對應你當下真實的資料與情境作答，而不是只能靠訓練時的舊資料硬答。
MCP 和一般 API，有什麼差異？
傳統 API 的呼叫邏輯，是開發者事先寫死的。一個端點對應一個固定用途，AI 想用，得照著文件先寫好程式碼，才能去呼叫。MCP 則是讓 AI 在對話當下，自己動態「發現」有哪些工具可用，自行判斷要不要呼叫、該呼叫哪一個，而且同一個 MCP Server，不會因為換了另一家 AI 模型就得重新改寫。
MCP 其實是建立在既有的 function calling 機制之上做標準化，不是要取代 API，也不是要取代 function calling 本身。真正的差別在「可控性」這一層。API 的呼叫時機與邏輯是開發者事先寫死的，行為可以完全預期；MCP 則是把「什麼時候呼叫、呼叫誰」這個判斷，交給 AI 自己去決定。這個決策權從人手上轉移到模型手上，不只是技術規格的差異而已，後面談資安風險時，也會回頭談到這一步轉移帶來的問題。這種把決策權交給 AI 的設計，也是為什麼 MCP 能跳脫特定廠商，變成一套人人可用的共通規格。
支援 MCP 的平台：從桌面助手到開發工具
MCP 已經不是 Anthropic 自己圈內的東西，這點從支援名單就看得出來。AI 助手這端，Claude Desktop 與 Claude Code 都原生支援；OpenAI 已經在 2025 年 3 月讓 Agents SDK 支援 MCP，ChatGPT 也在同一年陸續跟進；Google DeepMind 同樣在這一年開始採用，把 MCP 用在串接自家模型與外部資料來源上。
開發工具這端也一樣，微軟把 MCP 整合進 Visual Studio Code 與 Copilot Studio，程式碼編輯器 Cursor，以及 JetBrains 旗下多款整合開發環境（IDE），都陸續加入支援。換句話說，不管你平常用哪一套工具寫程式、跟哪一家 AI 對話，MCP 已經悄悄鋪成一張共通的底層網路。
伴隨這張網路一起成長的，是社群與官方一起維護的 MCP Server 數量，如今已經到了數千個規模，涵蓋資料庫、雲端服務、開發工具等各種類型，而且還在持續增加中。只是，平台越多人用、伺服器越多人架，曝露在外的風險也跟著同步放大。
企業導入 MCP，要提防哪些資安風險？
MCP 把「什麼時候呼叫工具」的判斷權交給 AI 之後，也跟著帶來幾個新的資安課題，尤其是企業想把 MCP 導入內部系統之前，得先弄清楚這幾件事。
第一個風險，是大量公開曝露在網路上、卻缺乏驗證機制的 MCP Server。資安研究公司 Knostic 用 Shodan 掃描全網，找出 1,862 台曝露在公開網路上的 MCP Server，抽樣人工驗證後，這些伺服器全數沒有任何身分驗證，任何人只要連得上，就能直接看到內部工具清單、甚至進一步存取敏感資料。Backslash Security 的另一份調查也發現，有數百台 MCP Server 被設定成綁定所有網路介面，其中不少配置甚至能讓同一網路上的任何人直接執行任意指令。這類問題多半不是協定本身有洞，而是架設的人沒有把該鎖的存取權限鎖好。
第二個風險，發生在協定與 SDK 設計層級，而且規模大上不少。2026 年 4 月，資安研究公司 OX Security 揭露一項牽涉 MCP 官方 SDK 本身的設計缺陷。問題出在 stdio 這種本機傳輸方式上，在特定情況下，外部傳入的設定值未經清理就會被當成系統指令直接執行，這不是單純的程式錯誤，而是內建在 Python、TypeScript、Java、Rust 等各語言官方 SDK 裡的架構性選擇。
受影響的規模不小：超過 1.5 億次的 SDK 下載量、7,000 多個公開曝露的伺服器，估計最多有 20 萬個執行環境受影響，連 Cursor、VS Code、Windsurf、Claude Code、Gemini-CLI 這些主流工具都在受影響之列。Anthropic 對此的回應是，這個行為屬於設計上的預期結果，拒絕修改協定本身，理由是 stdio 的執行模型本來就代表一種安全的預設值，清理輸入的責任在開發者身上，不在協定。
第三個風險比較抽象，卻是 MCP 讓 AI「主動判斷」之後才會出現的新問題，叫做 prompt injection（提示注入）。當 MCP 從外部資料源讀進來的內容裡，藏著一段其實是寫給 AI 看的指令，AI 有可能把這段話當成使用者本人下的指令去執行，而不是單純的參考資料。Hou 等人 2025 年一篇分析 MCP 生態系資安風險的研究就指出，這種風險跟傳統 API 呼叫不一樣。傳統 API 的呼叫邏輯是寫死的，不會把收到的資料內容誤判成新的指令；MCP 因為把決策權交給了 AI 本身，才第一次讓這種「資料裡藏指令」的攻擊有機可乘。
面對這些風險，目前官方建議的緩解方向，一個是前面提過的 human-in-the-loop，重要操作動手之前，先跳出提示讓使用者確認，而不是讓 AI 自己說了算；另一個是嚴格限制每個 Server 拿到的權限範圍，一個負責讀取天氣的 Server，就不該同時擁有寫入資料庫的權限。但這兩件事實際有沒有落實，得看每一個 Host 與 Server 自己怎麼做，不是裝上 MCP 就自動獲得保障。
MCP 併入 Linux Foundation，治理模式怎麼變？
前面提到的資安風險，很大一部分靠的是社群共同把關，而這種共同治理的精神，跟 2025 年底一項治理決定直接相關。2025 年 12 月，Anthropic 把 MCP 捐給了 Linux Foundation 底下新成立的 Agentic AI Foundation（簡稱 AAIF），由 Anthropic、Block、OpenAI 共同發起，Google、微軟、AWS、Cloudflare、Bloomberg 等企業也加入支持。MCP 與 Block 的 goose、OpenAI 的 AGENTS.md，並列為 AAIF 最初的三個創始專案。
真正改變的，不是誰在管日常維運，而是 MCP 現在掛在哪裡。原本負責 MCP 技術方向的維護者團隊，捐贈之後仍然照舊，繼續透過既有的提案討論流程決定協定怎麼演進，日常維護沒有中斷。改變的是制度上的位置，MCP 的商標、資源與機構歸屬，從 Anthropic 一家公司底下，搬進一個不隸屬任何單一企業的中立基金會。
這個位置上的改變，說明了為什麼原本互為競爭對手的大型平台，會願意一起參與同一套標準。錢與機構事務歸基金會管，協定的技術方向仍然握在維護者手上，Anthropic 商業利益與協定治理之間的界線，也因此比之前更清楚。當一套規格不再被外界視為某一家公司隨時可能改變遊戲規則的工具，其他平台自然更敢把自己的產品也押上去。
回到文章開頭那個矛盾，AI 明明已經很聰明，為什麼還是碰不到你電腦裡的檔案、公司內部的資料。答案從頭到尾都不在模型的能力，而在於過去沒有一套大家都認的共同語言。搞懂 MCP 是什麼協定、又怎麼運作之後就會發現，它補上的正是這一塊拼圖。
當這套協定連治理權都已經交給中立的基金會，連原本互相競爭的大型平台都願意共用同一套規格，AI 能碰到的世界只會越來越大。但這也代表使用它的人，得跟著多懂一點工具是怎麼被交出去的，又是誰在把關。權限開得越大，越需要有人盯著授權提示，而不是每次都直接按下同意。