MCP 是什麼？它讓 AI 接進你的系統有了共同規格，開多大仍是你的決定
MCP（Model Context Protocol，模型上下文協定）是一套讓 AI 應用連接外部系統的開放標準，2024 年 11 月由 Anthropic 發布，2026 年 7 月完成改版。這篇從台灣零售品牌行銷主管的角度回答 MCP 是什麼：它的三個角色對應到你公司裡的什麼、伺服器掛出去的三類東西怎麼分、品牌會在哪些地方真的撞到它，以及哪些事情協定不會替你決定。
先給一句話的答案。MCP 全名 Model Context Protocol，中文譯作模型上下文協定，是一套讓 AI 應用連接外部資料、工具與工作流程的開放標準，由 Anthropic 在 2024 年 11 月發布。它規範的是「AI 應用與外部系統怎麼對話」這件事。至於 AI 最後看得到什麼、能做到什麼程度，取決於伺服器掛出了哪些功能、你給了什麼授權，以及你用的 AI 應用允許什麼。協定把通道標準化，開多大這件事留在原地，等品牌自己決定。
以下把這句話拆開，用零售品牌的語言講一遍。
你的廣告平台上個月開了一個 MCP 伺服器，這則公告多數行銷團隊沒讀到
2026 年 8 月 31 日，Microsoft Advertising 在官方部落格寫了一段話：它的 MCP 伺服器進入開放試行，用唯讀方式把即時的廣告帳戶資料接給 AI 助理，可以搭配 Microsoft 365 Copilot、ChatGPT 與 Claude 使用。同一篇貼文舉的例子裡，有代理商拿它做橫跨 120 個以上帳戶的成效稽核儀表板，也有媒體平台把原本要花數小時的活動稽核壓縮到數分鐘。
這件事的意義不在某一家廣告平台又發了什麼功能。意義在於，讓 AI 直接讀取廣告資料這件事，已經從技術圈的討論題，變成寫在產品公告裡、要你去設定啟用的選項。而讓它成立的那個東西，叫做 MCP。
要說明的是，平台開了伺服器，跟你的帳戶已經被 AI 讀取，是兩回事。中間還隔著設定、驗證與授權，需要有人按下同意。這篇文章想講清楚的，正是那個按鈕背後到底連著什麼。
那行寫在月報最後一頁的小字，問出了一個經營者本來就該問的問題
以下是一個綜合了常見情況的情境，用來說明問題長什麼樣子。
一位行銷主管收到代理商寄來的月報，翻到最後一頁，看見一行以前沒有的小字：本報告由 AI 助理透過官方 MCP 讀取即時資料產出。她盯著那行字看了一會兒，接著問了兩個問題。前一個是這樣做出來的數字準不準。後一個她問得比較遲疑：所以我們的帳戶，現在是誰在看。
她的遲疑很合理。有東西被打開了，而打開的過程沒有人來問過她。我們把這篇文章寫成她那兩個問題的答案，不需要懂怎麼寫程式也讀得完，要做的只是把這套架構攤開，看看每一塊對應到你公司裡已經有的什麼。
MCP 的骨架，對應到你辦公室裡本來就存在的角色
MCP 官方文件給的定義是：一套用來把 AI 應用連接到外部系統的開放標準，涵蓋資料來源、工具與工作流程。Anthropic 在 2024 年 11 月 25 日發布它的時候，講的問題很白話：AI 模型被困在資訊孤島與舊系統後面，而每接一個新的資料來源，就得客製一套接法。
官方架構文件把參與者分成三種：
| 名詞 | 一句話定義 |
|---|---|
| MCP 主機（Host） | 協調並管理一個或多個連線的 AI 應用本身 |
| MCP 客戶端（Client） | 維持與某一台伺服器的連線、替主機取得脈絡的元件 |
| MCP 伺服器（Server） | 對外提供脈絡與能力的那支程式 |
換成你辦公室裡的東西來看，主機就是你團隊實際打開來用的那個 AI 應用，可能是 Claude、ChatGPT，也可能是代理商在用的工具。它是發問的那一方，也是決定要連上誰的那一方。
客戶端是主機替每一台外部伺服器各自開的一條專屬連線。主機連五台伺服器，就會開五條各自獨立的連線。這個結構的實用價值在於盤點：連線關係可以按伺服器一台一台列出來，你會拿到一份清單。至於每一條線是否需要單獨核准、授權範圍能切多細，則要看你用的 AI 應用、那台伺服器，以及公司的身分系統怎麼實作，協定本身沒有規定。
伺服器則是掛在系統旁邊、負責對 AI 說明「這裡有什麼、可以怎麼用」的那支程式。它可以是廣告平台官方做的，可以是你的電商或會員平台做的，也可以是網路上某個人寫的。這三種來源的可信程度差很多，後面會回頭談。
至於 MCP 跟你們工程團隊已經在用的 API 之間怎麼分工，我們在談這場接軌標準轉變的那篇拆得比較細，這裡只留一句：MCP 不取代既有的 API，許多伺服器會在後方呼叫既有的 API 來完成實際動作。
零售品牌真正撞到 MCP 的地方，多半不在 IT 部門
理解了骨架，接下來的問題比較實際：一個賣衣服、賣保養品、開連鎖門市的品牌，什麼時候會真的碰到這個詞。實務上常見的接觸點有這幾種，而且它們大多不是從 IT 部門開始的。
- 廣告平台。除了前面提到的 Microsoft Advertising，Google Ads 也開了官方 MCP，目前公開的功能同樣以查詢為主，改動帳戶的操作留在原本的 API 流程裡。這個設計選擇背後的考量，我們在拆解 Google Ads 為什麼只給看不給動的那篇談過。Meta 那邊的開放程度與限制跟 Google 不一樣，Meta MCP 接起來能做什麼、做不到什麼另外有一篇；如果你手上同時有好幾個平台，Google、Meta、TikTok 的 Ads MCP 該先接哪一個那篇有排序建議。對品牌的實際意義是：你的代理商如果已經用 AI 助理拉即時報表，那條線很可能就是 MCP。
- 你自己的系統要不要對外開放。當團隊開始問「能不能讓 AI 直接查會員的近期訂單」，這句話翻譯過來就是要不要替會員系統掛一台 MCP 伺服器。這是一項關乎營運與資安的決策，決策點不在工程。
- 同事自己裝的。這一種最容易被忽略，也最容易出事。MCP 伺服器的安裝門檻不高，一個熱心的同事在自己的 AI 工具裡接上一台從網路上找來的伺服器，風險分成兩種：裝在自己電腦上跑的，等於讓一段別人寫的程式在能接觸公司檔案的地方執行；連到遠端的，則是把請求內容、資料與存取權杖交給一個你不認識的服務。別人寫的擴充可能借走你手上的資料權限這件事，是我們認為零售品牌現階段最該先建立審查流程的一塊。
這幾種接觸點的共同點是，它們都不會經過一份正式的採購評估。它們用比較安靜的方式發生，等到有人看見月報上那行小字，事情已經在跑了。
掛出去的東西分成三類，但風險高低要另外一條軸來看
如果整篇只能記一件事，我們希望是這一件。
MCP 伺服器對 AI 掛出去的東西，2026-07-28 版規格分成三類：
| 名詞 | 一句話定義 |
|---|---|
| 工具（Tools） | 讓 AI 模型執行的函式 |
| 資源（Resources） | 提供給使用者或模型使用的脈絡與資料 |
| 提示範本（Prompts） | 給使用者選用的樣板化訊息與工作流程 |
換成零售場景，資源可能是商品分類表、會員欄位的定義、檔期活動的排程。工具可能是查詢某位會員的近期訂單、圈出一群受眾，或是調整某個廣告組的預算。提示範本則是預先配好的任務起手式，例如一份跑月度成效檢視的固定流程，由人挑選使用。
這裡有一個很容易誤讀的地方，值得特別點出來：這三類講的是「掛出去的東西屬於哪一種形式」，跟「風險有多高」是兩條不同的軸。官方文件舉的工具範例包括查詢資料庫與查天氣，兩個都只是讀取，不會改動任何東西。反過來說，資源雖然只提供資料，內容也可能是一份完整的會員名單。用類型來推斷風險，兩邊都會判斷錯。
所以當有人來問要不要開放某個系統，光知道它屬於哪一類還不夠，要逐項確認這幾件事：這個功能是讀取還是會寫入、碰到的資料有多敏感、範圍涵蓋幾個帳戶、執行前要不要人工確認、事後有沒有留下紀錄。這五個問題問完，你才真的知道自己開了多大。
值得一提的還有清單本身。AI 會先向伺服器要一份工具清單，上面每項都附著名稱、說明與需要哪些參數，模型讀完可以自己提出要呼叫哪一個，實際會不會執行仍受主機政策與人工確認限制。這也是為什麼伺服器該做成意圖導向的工具設計會影響成效。
還有一個常見的混淆：MCP 管的是 AI 接不接得到東西，拿到之後該照什麼章法處理是另一層的事，關於 Skill、Prompt 與 MCP 各自回答什麼問題，我們另外整理過一份對照。反過來說，也不是每件重複的工作都值得做成 MCP，同一件事該接成 skill、MCP 還是 CLI那篇算過掛錯的成本。
這一年協定往企業級長，但身分這一題還是留給品牌
會過期的東西要標時間，所以把最近這一年的變化交代清楚。
治理層面先定了。2025 年 12 月 9 日，MCP 成為 Agentic AI Foundation 的創始專案，這個基金會設在 Linux 基金會底下，共同發起者包括 Anthropic、Block 與 OpenAI。MCP 官方團隊在同一篇文章揭露，當時每月 SDK 下載量超過 9,700 萬次，活躍伺服器 10,000 台。協定交給中立組織治理，降低了單一供應商說收就收的風險，不過協定成熟度、各家產品的支援程度與資安要求仍然會變，值得每年重新檢視一次。
規格層面在 2026 年 7 月完成了一次大改。官方部落格在 2026 年 7 月 28 日發布 2026-07-28 版規格，由兩位主要維護者 David Soria Parra 與 Den Delimarsky 署名，他們形容這是協定推出以來最大的一次修訂。最核心的改動是把協定改成無狀態：以前一條連線要先握手、由伺服器記住彼此是誰，現在每一次請求都自己帶齊版本與身分資訊。
無狀態聽起來很技術，白話的商業含意是這樣：伺服器不必再替每一條連線保管記憶，因此可以像一般網站服務那樣加機器擴充。對品牌的意義是，把這種服務養在企業環境裡的工程負擔往下降了一階。要注意的是，協定無狀態並不代表你的業務流程不能記住東西，需要記住的狀態，伺服器仍然可以自己管。
至於接下來要往哪走，官方在 2026 年 8 月 22 日發布的新版路線圖把 agent 身分與企業安全列為優先項之一，明講要處理的情境是「以雲端工作負載形式執行、擁有自己身分的 agent」。翻譯成品牌語言是：當 AI 開始代替人去動系統，它用的是誰的身分、出事了怎麼追，協定自己也還在解。
也就是說，這一題現在仍然是品牌自己的功課。當 AI 變成一種非人類身分，權限怎麼給、怎麼收、怎麼留紀錄，沒有任何協定會替你決定。
跨陣營的支援倒是已經很穩。OpenAI 官方文件把 MCP 描述為「正在成為業界標準的開放協定」，並說明如何在 ChatGPT 與 Responses API 裡連上遠端伺服器。競爭對手同時支援同一套協定，這件事在科技業不常見。
不過你可能也讀過相反的說法。2026 年有一波論調主張 MCP 已經被 Agent Skills 那類做法取代，品牌不必再投入。這個爭論值得單獨看，MCP 已死了嗎，該退場的到底是什麼那篇把雙方的論點與實際數據攤開比對過。
接得上是一回事，AI 讀到的那份資料長什麼樣是另一回事
科技公司在底層協定上談成了共識，讓「接得上」逐漸變成通用能力。品牌的考驗從這裡才開始。
一個 AI 就算順利連上了四台伺服器，官網一份、APP 一份、門市 POS 一份、LINE 又一份，它讀到的仍然是四份對不起來的名單。同一位顧客在四邊各自是一個陌生人，AI 只會更有效率地產出四份互相矛盾的建議。
把跨通路的顧客對成同一個人，有不少種做法。資料倉儲、主資料管理、共用一組會員鍵，都可能解掉一部分。CDMP（Customer Data Management Platform，顧客數據管理平台）處理的是零售場景裡比較麻煩的那一段：線上線下同一個人的歸戶、把行為變成看得懂的標籤、把購買機率這類訊號先算好。等到要對 AI 開放的時候，掛出去的才有辦法是「找出七天內高回購意圖的會員」這種業務問句，而不必讓 AI 自己去猜十幾張表該怎麼接起來。
順序上，這件事比選哪一家 AI 更早需要處理，而且不綁定任何一家。AI 代理購物時代的資料困局談的就是這個落差：模型換一輪只要幾個月，會員資料歸戶做不好，換幾輪都一樣。
在 IT 排上議程之前，行銷端可以先起頭的事
以下幾件事行銷端可以先發起，其中涉及驗證、歸戶與權限政策的部分，仍然要跟 IT、資安一起完成。
- 盤點你團隊現在用的 AI 工具連了哪些伺服器，包含代理商那邊在用的。行銷端先問一輪拿到初稿，再請 IT 或資安對照 AI 工具的管理後台、授權紀錄與允許清單核實（預期效果：把安靜發生的事情變成一份查得到的清單；建議週期：兩週內問完一輪，之後每季更新）。
- 對每一個已經接上的功能，逐項標記它是讀取還是會寫入、碰到哪些資料、涵蓋幾個帳戶。同一台伺服器上不同功能的答案會不一樣，要拆到功能層級才有意義（預期效果：授權討論從一個開關變成逐項決定；建議週期：跟資安或 IT 一起排，一個月內出第一版）。
- 替第三方伺服器訂一條審查流程，規定同事不能自行安裝未經檢視的擴充（預期效果：擋掉最容易出事、也最沒有紀錄的那條路；建議週期：越早越好，一週內先發一封內部說明）。
- 找一個唯讀、低風險的官方伺服器，讓團隊實際接一次看看。親手走過一遍授權流程，比讀十篇說明都清楚，不會寫程式的人怎麼把第一支 MCP server 裝起來用那篇有逐步的做法（預期效果：把抽象的協定變成團隊摸過的東西；建議週期：找一個下午跑完）。
- 如果你的目標涉及跨通路的會員與訂單，先完成身分對應與資料品質檢查再談開放，同時挑三到五個團隊每個月都會問的業務問題，把它們寫成明確的問句，例如「找出過去 30 天消費超過 3,000 元、但最近 7 天沒有回訪的會員」。這些問句就是未來掛出去的工具該長的樣子。只讀廣告成效或商品資訊的情境，不必等這一步（預期效果：AI 接上後讀到的是一位完整的顧客，伺服器做出來也能直接用；建議週期：用一季完成資料源清點、歸戶規則與第一批問句）。
這幾件事的共同點是，它們都不依賴你最後選哪一家 AI，卻決定了任何一家接進來之後好不好用。
回到月報上那行小字
那位行銷主管的後一個問題，其實比前一個重要。數字準不準，還有辦法查：把它跟後台的原始報表、欄位定義、時區與歸因口徑逐項核對就知道了。帳戶現在是誰在看，沒有人主動說，就永遠不會有人說。
MCP 是一套把 AI 接上外部系統的開放標準，這是它的定義。對一個經營品牌的人來說，它帶來的則是一組本來不存在的問題：你的會員資料、廣告帳戶、訂單系統，哪些對 AI 開了、開到什麼程度、是誰按下同意的。協定把接得上這件事變成了通用能力，剩下的判斷留在原地。
那行小字的意思是，通道已經鋪好了。值得慶幸的是，現在還來得及決定它通到哪裡。
品牌最常問的 MCP 問題
Q1：MCP 是什麼？
A1：MCP 全名 Model Context Protocol，中文譯為模型上下文協定，是一套讓 AI 應用連接到外部資料、工具與工作流程的開放標準，由 Anthropic 在 2024 年 11 月 25 日發布，目前通行的規格版本是 2026-07-28 版。它定義了三種角色：主機是 AI 應用本身，客戶端是主機為每台外部伺服器開的專屬連線，伺服器是掛在系統旁邊、對 AI 說明有哪些能力可用的程式。要注意的是，協定規範的是連接與呼叫的方式；AI 最後看得到什麼、能做到什麼程度，由伺服器掛出哪些功能、授權範圍與主機政策共同決定。
Q2：MCP 跟 API 有什麼不同？我們現有系統要打掉重做嗎？
A2：不用重做。差別在使用對象：API 是寫給工程師與程式的溝通合約，呼叫方式要事先寫死；MCP 是寫給 AI 模型的，模型連上之後會拿到一份工具清單，可以自己提出要用哪一個。兩者的關係是疊加，許多 MCP 伺服器會在後方呼叫既有的 API 來完成實際動作。多數品牌要做的是額外架一層。這兩者的逐項對照，我們在另一篇專文裡拆得比較細。
Q3：哪裡可以免費使用 MCP？要怎麼開始？
A3：MCP 是開放標準，協定本身免費，官方在 modelcontextprotocol.io 提供完整規格、開發文件與參考實作。實務上多數品牌的第一次接觸不需要自己動手：Claude、ChatGPT、Microsoft 365 Copilot 這類 AI 應用都已內建連接功能，廣告平台也陸續推出官方伺服器。實際能不能用得看幾個條件，包括你的方案等級、公司管理員是否開放、以及授權設定是否完成。想自己動手試一台，我們另外寫過不會寫程式的人怎麼把第一支 MCP server 裝起來用。至於替自家系統做伺服器那一段，會牽涉權限設計與資安審查，建議跟 IT 一起評估。
Q4：預算有限的中小品牌，現在需要投入 MCP 嗎？
A4：不必急著自建。比較務實的順序是先用現成的：廣告平台的官方伺服器目前多半只提供查詢功能，能降低誤改帳戶的風險，接上就能省下手動拉報表的時間。要提醒的是，唯讀只降低了改動的風險，資料被帶到哪裡去仍然要看你連的是誰，來源不明的伺服器不因為唯讀就安全。同時把不花錢的地基做起來，包括會員歸戶、盤點哪些系統該對 AI 開放、把常問的業務問題寫清楚。這些投入不綁定任何一家 AI。
Q5：接上 MCP 之後，多久看得到效果？
A5：取決於你接的是哪一段。接現成的唯讀伺服器來做報表彙整，取代的是明確的重複工時，通常在完成授權設定後的第一個報表週期就會有感覺。若目標是讓 AI 讀懂自家的會員與訂單資料，時間取決於資料底座的整理程度，跨通路資料還沒歸戶的話，光是整理到 AI 讀得懂就可能要數個月。這裡給的是規劃用的估算範圍，實際時程會因資料源數量與品質差很多，建議先挑一個窄場景跑通再談放大。
Q6：讓 AI 透過 MCP 連進系統，風險在哪？
A6：主要有三類。權限給太寬是最常見的一種，把會寫入的功能跟只供查詢的功能包在同一次授權裡送出去。來源不明的第三方伺服器是另一種，裝在本機的等於讓別人寫的程式在能接觸公司檔案的地方執行，連到遠端的則是把資料與存取權杖交了出去。剩下一種是身分與追溯，AI 代替人動系統時用的是誰的身分、出事怎麼追，官方在 2026 年 8 月的路線圖裡把這題列為待處理的優先項，代表現階段仍要靠品牌自己的治理流程補上。官方規格也明列，使用者必須明確同意並理解所有資料存取與操作。