一句話定義

MCP（Model Context Protocol，模型上下文協定）是一套開放協定，用途是讓 AI 應用以統一的方式連上外部工具與資料來源。

30 秒看重點

  • 是什麼：MCP 是 Model Context Protocol 的縮寫，一套規定「AI 應用怎麼跟外部工具講話」的開放協定。
  • 為什麼重要：有了它，工具做一次就能被各家 AI 用，不必為每個 AI 產品各寫一份接法。
  • 跟誰相關：想把公司資料接進 AI 的工程師、評估導入 AI 的主管，還有天天在裝 AI 外掛的一般使用者。
  • 最常見的誤解：以為 MCP 是一個 AI 模型或某個軟體，其實它只是一份規格，本身不會思考。
  • 記住這件事就夠了：MCP 管的是「怎麼接」，不管「接上去之後 AI 聰不聰明」。

MCP 到底是什麼？

MCP 是一套開放協定，官方規格的定義很直白：「一個開放協定，讓 LLM 應用與外部資料來源、工具之間能無縫整合。」它規定的是通訊格式，不是模型也不是產品。你不會「用 MCP 回答問題」，你是讓某個 AI 應用透過 MCP 去拿它本來拿不到的東西。

官方規格說它的靈感來自 LSP（Language Server Protocol）。LSP 統一了「編輯器怎麼支援一種程式語言」，一個語言做一份 language server，各家編輯器都能吃；MCP 想對 AI 應用做的是同一件事。訊息格式用 JSON-RPC 2.0，一種早就存在的遠端呼叫規格，沒有什麼神秘的新發明。

生活比喻：你可以想像成悠遊卡。悠遊卡本身不會載你去任何地方，它只是把「怎麼扣款」這件事講定，所以同一張卡刷得動公車、捷運、超商跟 Ubike，店家也不必為每家發卡公司各擺一台讀卡機。MCP 就是 AI 世界的那套刷卡規格，AI 是那台讀卡機，工具跟資料是後面各自的系統。

為什麼會有 MCP？

MCP 的出現，是為了解決「每個 AI 應用都要為每個工具重寫一次接法」這個乘法問題。

在它出現之前，你想讓 AI 讀得到公司的 Google Drive、查得到資料庫、開得了 GitHub issue，就得為每一組「AI 產品 × 外部系統」各寫一份整合。三個 AI 應用要接五個系統，就是十五份程式碼各自維護，換個模型再重做一次。老實講這種活沒人想幹。

第二個問題是知識邊界。模型訓練完就停在那個時間點，公司內部文件、今天的訂單、你的行事曆，它一概不知道。「那不能每次複製貼上給它嗎？」可以啊，但你不會想每天做二十次。

MCP 的解法是拆成兩邊：工具那邊照規格做一個 MCP server，AI 應用那邊照規格當 client，中間講同一套話。官方 TypeScript SDK 的說法更精準，MCP 是「把提供上下文這件事，跟真正跟模型互動這件事分開」。

MCP 是怎麼運作的？

運作方式很單純：一邊是提供能力的 server，一邊是想用能力的 client，兩邊用 JSON-RPC 2.0 互傳訊息。規格把參與者分成三種角色：

  1. Host（主應用）：你實際在用的那個 AI 應用，負責發起連線。
  2. Client（連接器）：住在 host 裡面，一個 client 對接一個 server。
  3. Server（伺服器）：提供上下文與能力的那一方，例如包住某個資料庫或 API 的小程式。

Server 能提供三種東西，名字從 2024 年第一版規格定下來就沒變：Tools（AI 可以執行的功能）、Resources（給使用者或模型看的資料）、Prompts（模板化的訊息與流程）。官方 SDK 的連線方式支援 stdio（跑在你電腦上的子行程）與 Streamable HTTP（走網路），所以 MCP server 可以是本機一支小程式，也可以是遠端服務。

名詞小教室：JSON-RPC 是一種「用 JSON 格式打電話給遠端程式」的老規格。你可以想像成一張填好的表單：上面寫要找哪個功能、帶什麼參數，對方照表單辦事再把結果填回來。MCP 沒有自己發明語言，只是規定這張表單長什麼樣。

MCP 跟函式呼叫（Function Calling）差在哪？

一句話講清楚：函式呼叫是模型「說出它想用哪個工具」的能力，MCP 是「工具要怎麼被接上來」的協定，兩者是上下游不是競爭關係。

比較項目MCP（模型上下文協定）函式呼叫（Function Calling）
管的是什麼AI 應用與外部系統之間怎麼連線、怎麼傳訊息模型怎麼表達「我要呼叫哪個功能、參數是什麼」
誰在說話應用程式與 MCP server模型與它的 API
你要寫幾份一個工具做一次，任何 MCP client 都能用每家模型 API 各有自己的定義格式
換掉模型會怎樣server 不用改工具定義通常要跟著改
我會在什麼情況用它想把同一批工具給多個 AI 應用共用只在單一模型 API 上做一件事

從這張表可以看出來，這兩個詞被混著用不是因為誰取代誰，而是它們根本在講不同層。要讓 AI 會用工具，模型端得有函式呼叫的能力；要讓那個工具「做一次就到處能用」，才需要 MCP。

你會在哪些地方碰到 MCP？

只要一個 AI 產品開始強調「可以連你自己的資料」，背後就很有可能是 MCP 在跑。

  • 各家雲端與開發工具：MCP 官方 2026 年 7 月 28 日的新版規格公告裡，背書的生態夥伴就包含 AWS、Google Cloud、Microsoft 與 Cloudflare（誰都不想讓對手訂規則）。
  • AI 廠商自家的連接器：像我們日報寫過 Anthropic 推出 Claude for Teachers，方案裡就附了教育專用的 MCP 連接器。
  • 這個站台本身：你正在看的這篇文章，選題時就是透過一個 Ubersuggest 的 MCP connector 去查台灣搜尋量的（對，寫百科的流程自己也在吃這套規格）。

如果你是工程師，最快碰到它的地方是官方 SDK。依 2026-07-28 版公告，Tier 1 SDK 涵蓋 TypeScript、Python、Go、C#，Rust 版還在 beta。Python SDK 加個 @mcp.tool() 裝飾器就能把函式變成工具，說真的門檻比想像中低。

關於 MCP 最常見的 3 個誤解

  1. 誤解一：MCP 是 Anthropic 的專屬技術 — 它 2024 年 11 月由 Anthropic 開源，第一版規格日期 2024-11-05，採 MIT 授權，建立者是 David Soria Parra 與 Justin Spahr-Summers。據 TechCrunch 報導與 Linux Foundation 公告，2025 年 12 月 9 日 MCP 已被捐給 Linux Foundation 底下新成立的 Agentic AI Foundation，由 Anthropic、Block、OpenAI 共同創辦，Google、Microsoft、AWS 也都在名單裡。它現在是中立治理的專案。
  2. 誤解二：裝了 MCP server 就等於安全的官方外掛 — 剛好相反。官方規格的安全原則寫得很重：呼叫工具等於執行任意程式碼，必須取得使用者明確同意，而且工具的描述文字除非來自可信任的伺服器，都應該視為不可信。我們日報報導過的 Agentjacking 攻擊就是這條原則的實戰版，一句話就被騙走權限真的很痛 QQ。
  3. 誤解三：MCP 只有工程師需要懂 — 你不用會寫，但你會被它影響。以後「這個 AI 能不能接我的工具」會變成選產品的條件，就像當年選手機要看它吃不吃記憶卡。

想多了解 MCP，從哪開始？

沒有技術背景的話，先做一件事就好：去看你在用的 AI 產品有沒有「連接器」「Connectors」「MCP」這類設定頁，點進去看它想拿你哪些權限。這一步比讀懂協定有用得多。

有技術背景的話，照官方 Python SDK 的範例寫一個只有兩個函式的 server，掛進你平常用的 AI 應用，體感會完全不同。想更深入就讀 2026-07-28 版規格，它把協定核心改成無狀態、拿掉 initialize 握手與 session ID，讓請求可以落在負載平衡後面的任何一台機器，是到目前為止最大的一次改版。

常見問題 FAQ

MCP 跟 AI 有什麼關係？

MCP 本身不是 AI，它是一套規定 AI 應用怎麼連接外部工具與資料的協定。AI 模型負責思考與生成內容，MCP 負責讓模型手上有工具可用、有資料可讀。兩者是分工關係，缺了 MCP，AI 還是能聊天，只是碰不到它訓練資料以外的世界。

為什麼 MCP 突然這麼紅？

因為 2025 到 2026 年這波 AI 產品都在往「會動手做事的 AI」發展，而會動手就必須連外部系統。Anthropic 在 2024 年 11 月開源 MCP，之後主要 AI 與雲端業者陸續跟進，2025 年 12 月 9 日更被捐給 Linux Foundation 底下的 Agentic AI Foundation 交由中立治理。一件事被大廠共同認成標準，它就會出現在每一份技術文件裡。

我不是工程師也需要懂 MCP 嗎？

懂到「它是一條授權過的通道」這個程度就夠了。在 AI 產品裡看到連接器設定時，你會知道那是允許 AI 去讀某個系統的資料或執行某些動作，不是單純打開一個功能，這會直接影響你要不要按下同意。

MCP 的中文翻譯有沒有統一？

沒有完全統一，台灣的技術報導常見直接用英文縮寫 MCP 或原文 Model Context Protocol，中文譯名以「模型上下文協定」較常見。本站統一寫「模型上下文協定（MCP）」，同一篇文章內固定用法，避免同一個概念出現多種說法。

學會 MCP 之後，下一個該學什麼？

建議照這個順序：先看 AI Agent 與代理式 AI，理解「會動手的 AI」在幹什麼；再看工具呼叫與函式呼叫，那是模型端的對應能力；最後看提示詞注入，那是這套架構最現實的風險。四個詞湊起來，你就看得懂多數 AI Agent 新聞在吵什麼了。

延伸閱讀

參考來源

  1. MCP 規格 2026-07-28 版（官方 GitHub） — MCP 定義、host / client / server 架構、JSON-RPC 2.0、安全與信任原則。
  2. MCP 規格 2024-11-05 首版（官方 GitHub） — 第一版規格日期與初始定義。
  3. The 2026-07-28 Specification（MCP 官方部落格） — 無狀態核心、header 路由、Tier 1 SDK 名單與生態夥伴背書。
  4. MCP Python SDK（官方 GitHub） — server 能提供的三種能力與 stdio / Streamable HTTP 傳輸方式。
  5. MCP TypeScript SDK（官方 GitHub） — 「把提供上下文與模型互動分開」的定位，以及 v2 對應規格版本。
  6. MCP 規格倉庫 README（官方 GitHub） — 建立者姓名與 MIT 授權。

整理一下重點：MCP 真的沒那麼玄，它就是 AI 世界的刷卡規格，把「工具怎麼接上來」講定一次，剩下的聰不聰明還是看模型。

希望這一篇有讓你對 MCP 有比較具體的理解哩～如果發現事實錯誤、定義不準、或翻譯卡卡的，歡迎透過聯絡頁指正，看到我們會盡快修。

我們下篇文章見囉～

本條目由 Array 報報 AI 編輯部根據上方「參考來源」整理，文末已揭露 AI 生成 + 公開資料引用。