MCP 如何運作？讓 AI 串接你的外部工具與資料

你讓 AI 幫你整理 Google Sheets 裡的業績數字，它回你一句「我沒辦法直接讀你的檔案」。你貼一段 API Key，它又說格式不對。你換另一個 AI 工具，整套接法要從頭來過。三個 AI、三套接法、三次白工。

問題來自整合介面分散：MCP 公開前，AI 應用多半依各自的外掛、函式呼叫或客製 API 接入資料，同一來源常須重複整合。憑證應依工具的安全設定保存，不能把 API Key 直接貼進對話。

快速重點整理：MCP（Model Context Protocol，模型脈絡協定）是一個開放標準，用來統一 AI 應用與外部資料、工具之間的連接方式。可以把它想成共用插座；相容的 Host、Client 與 Server 能共用一套協定，但仍要處理版本、認證、權限與實作差異，並非接上就保證互通。

這篇會把 MCP 從用途、架構講到安全與入門方式。對行銷或內容工作者來說，重點是理解它如何連接內部工作流；MCP 不是搜尋引擎抓取網站的新標準，也不會直接提高 SEO 或 AI 搜尋引用。

在聊 MCP 之前，先看 AI 工具最痛的「接線工程」

把問題先講清楚，你才會懂 MCP 在解決什麼。

假設你手上有 5 個 AI 助手，公司內部有 5 個資料來源（客戶資料庫、文件庫、Slack、行事曆、報表系統）。在沒有共通協定的年代，你要讓每一個助手都能讀每一個資料來源，就是 5 乘以 5，25 條客製化的整合線。多一個助手、多一個資料來源，線的數量就呈乘法成長。工程圈把這種局面叫做 N×M 問題。

換個方式想。十幾年前印表機市場就是這副德行：每買一台印表機，就要裝一顆專屬驅動程式；換台電腦，重裝；換個作業系統，再重裝。後來業界把列印介面標準化（PostScript、IPP、AirPrint），驅動程式地獄才慢慢收斂。AI 工具在 2024 年以前，就卡在這個「每接一個東西就要寫一條專屬驅動」的階段。

更現實的痛是：這些整合線沒辦法重複利用。A 團隊寫了一套「AI 接 Slack」的程式碼，B 團隊想接 Slack 還是得自己重刻一遍，因為沒有共通規格可以共用。結果全世界的開發者都在重複造同一個輪子。

MCP 希望讓 Host 與資料來源各自實作共通介面，減少重複寫接線的工作；N×M 到 N+M 是設計比喻，實務仍要處理認證、權限、版本與各 Host 的支援差異。

MCP 是什麼？一個讓 AI 「插上插座就有電」的開放標準

MCP 全名是 Model Context Protocol，中文常譯成「模型脈絡協定」或「模型上下文協定」。它在 2024 年 11 月由 Anthropic 公開（官方規格與文件），2025 年 12 月再捐贈給 Linux Foundation 旗下的 Agentic AI Foundation（AAIF），成為創始專案，技術方向仍由既有的維護者主導（見 MCP 加入 AAIF 的公告）。後續說明以 2025-11-25 版為基準；官方在 2026 年 7 月發布了 2026-07-28 修訂版，做了幾項結構性調整（協定走向無狀態、移除 initialize 握手，並將 Roots、Sampling、Logging 列入棄用流程），差異會在相關段落標註，完整變更見官方變更紀錄與2025-11-25 版規格；網站另有持續變動的 draft，實作時分清楚穩定版與草案。

你只要記住一個比喻就好：MCP 之於 AI 工具，就像 USB-C 之於電子產品。在 USB-C 出現以前，你的包包裡塞滿 Micro-USB、Lightning、圓孔、各種怪頭轉接線。USB-C 一統天下之後，一條線充手機、平板、筆電、耳機。MCP 想做的完全是同一件事，差別只在於：它統一的那條線，換成了「AI 模型怎麼拿到外部資料、怎麼呼叫外部工具」這條隱形的線。

有幾個關鍵字請先在腦袋裡掛上號：

• 開放標準：不是某家公司的私有 API，規格公開、SDK 開源，誰都能實作。
• 可補問使用者：相容的 Host 可處理 Server 提出的 Elicitation 請求；舊版 Sampling、Roots 與 Logging 在 2026-07-28 版進入棄用流程，不宜當成新整合的預設方案。
• 模型無關：協定不綁定特定 LLM，但能否使用仍取決於 Host 的支援與設定。

換句話說，MCP 把「AI 怎麼接外部世界」這件事，從每一個應用裡抽出來，變成一層共通的基礎建設。想知道 AI 助手怎麼演進到這一步，可以先看我寫的Claude 是什麼，把 AI 客戶端的基本輪廓抓回來，會更好理解下面要拆的架構。

拆 MCP 的三角：Host、Client、Server 各自做什麼

很多人看 MCP 會卡在角色分工。其實它就三個角色，我用一間公司來比喻。

用公司的場景講：Host 是公司本體（老闆是 AI 模型），Client 是老闆底下替每個外部供應商開的「對口專員」，Server 則是一個個外部供應商（會計師事務所、物流公司、倉庫）。專員跟供應商講好怎麼交接，老闆專心做決策，不用親自去跟每一家喬細節。

Server 是協定角色，不等同於固定的作業系統隔離邊界。本機 stdio 部署常由 Host 啟動子行程，遠端部署則是網路服務；容器、帳號、檔案權限與網路隔離要由部署者另行設計。不能因為使用 MCP，就假設 Server 異常時一定不會影響 Host 或資料。

Host 通常會為每個 Server 連線建立一個 Client，方便分開管理生命週期與能力。不過，真正的授權與隔離仍要靠 Host、作業系統、憑證與遠端服務的存取控制落實。

MCP 的三種能力：Tools、Resources、Prompts 怎麼分工

Server 對外提供的能力，分成三大類。這三類最大的差別，跟資料本身是什麼關係不大，真正的關鍵在於控制權在誰手上。這個切法很巧妙，直接決定了使用體驗。

同一個 Server 可以同時提供這三種能力，但「model-controlled、app-controlled、user-controlled」描述的是互動慣例，不是強制安全機制。Host 仍須正確實作授權、確認與存取控制，不能因為能力被分類就保證模型不會越權。

Resources 可讓 Server 提供文件、資料庫紀錄或其他可讀取資料，由 Host 決定怎麼呈現或交給模型；它本身不等於 RAG 素材庫，也不自帶切塊與向量索引。若要用取得的資料做檢索增強，應用仍須自行設計資料處理、權限、檢索與答案驗證。可對照RAG 是什麼，把協定接線與檢索工作流程分清楚。

至於 Prompts 為什麼要單獨成一類，是因為同一個工具搭配不同的提示範本，產出可以差十萬八千里。把高頻好用的範本封裝成 Server 提供的選項，可把團隊常用的互動起點重複使用；實際輸出仍受 Host、模型、資料與權限設定影響，不能保證一鍵重現同樣答案。對提示詞的基本功還不熟的話，先補一下Prompt 是什麼，會更容易抓到 Prompts 這一類的價值。

MCP vs Function Calling：差在哪、為什麼不能混為一談

這大概是新手最容易踩雷的地方。每次我講 MCP，一定有人舉手問：「這跟 Function Calling（函式呼叫）有什麼不一樣？ChatGPT 不是早就會叫工具了嗎？」

問得好，但答案不是「MCP 比較新所以比較強」這種敷衍版本。我把它拆給你看。

Function Calling 是模型的一項「能力」：LLM 能夠判斷「我現在需要呼叫某個函式」，然後吐出一段結構化的呼叫請求（通常是 JSON）。它解決的是「模型會不會開口要工具」這一步。但模型吐出 JSON 之後，那個 JSON 要送到哪裡、怎麼被執行、結果怎麼傳回來？這段「接線」全部是開發者的事，每一個應用都要自己刻一遍。

MCP 是一層「協定」：它標準化了工具怎麼被發現（列出 Tools/Resources/Prompts）、怎麼被呼叫、怎麼回傳、走什麼傳輸層。它不發明「模型會叫工具」這件事，而是替「工具與 AI 之間的整條管線」訂出共通規格。

用車來比喻。Function Calling 是引擎（模型能不能輸出動力），MCP 是傳動軸加輪胎介面（動力怎麼標準化地接到地面）。兩者是不同層、而且是互補關係。實務上，Host 常常就是把 MCP Server 提供的 Tools，包成 Function Calling 的格式餵給模型。模型用 Function Calling 開口，MCP 負責把那張單遞到對的 Server 手上。

老實說，這兩者根本不該拿來二選一。真正會拿來比的，是「MCP 出現以前的客製整合」對上「MCP 出現以後的標準整合」。前者是每家自己焊線，後者是大家用同一個插座。這才是 MCP 真正的比較對象。

實務怎麼選：直接打 API、接 MCP，還是先手動查再匯出

懂了協定跟能力，接下來的問題其實很務實：手上有一個資料來源，可能是關鍵字工具、報表系統或公司資料庫，到底該直接呼叫它的 API、接一個 MCP Server，還是維持現狀，需要時手動登入查一查、把結果匯出成試算表？這三條路常被講成新與舊的對立，其實它們是同一個資料需求的三種取得方式，各有清楚的成本結構。選錯的代價也不小：把一年只查四次的問題寫成 API 管線，是用好幾個人天的成本買一個用不到的自動化；反過來，把每天要跑的制式報表交給對話介面，每一輪都在付多餘的錢，數字口徑還會跟著提示句漂移。

先從最原始的路線講起，因為它是所有比較的基準線。手動查詢加匯出，工程成本是零，彈性最大，查詢的人自己看得到每個數字從哪個報表、哪組篩選條件來。它的成本全部落在人力時間與不可重現這兩件事：同一份分析下個月要再做一次，步驟得靠記憶與舊檔案重演；換一個人操作，篩選條件就換一套口徑。它適合的情境很明確：低頻、一次性、需要人眼判斷的查詢。一季做一次競品流量體檢的團隊，不需要任何自動化，把這個需求外包給程式反而是浪費。

第二條路是直接呼叫 API。初期開發投入較高：讀文件、寫程式、處理認證與錯誤、部署排程，之後每次執行不經過模型推理與對話往返，回應速度快、口徑由程式固定；資料端的計費依服務本身的單位規則走，帳目可以事先精算。對外開放 API 的服務，也常以 OpenAPI 這類機器可讀規格描述每個端點的請求與回傳格式，讓文件、SDK 產生與測試都吃同一份規格檔。Ahrefs 的 API 文件就是實例，端點參考內建 OpenAPI 相容規格，官方也直接提供完整的 spec 檔（見Ahrefs API 入門文件）。這條路要誠實面對的是維護：API 改版、憑證輪替、監控與除錯，都是上線之後持續存在的責任，它不是付一次錢就結束的工程。

第三條路是 MCP。在需要程式或 AI 代查的兩條路裡，它的起步門檻最低：Host 用現成的，Server 用別人寫好的，一段設定就能讓 AI 用自然語言查資料。但它的成本藏在兩個地方，而且兩邊都要算。資料這一側，先看 Server 背後是什麼：工具可能讀本機檔案、查資料庫或純做計算，這些動作不一定產生資料帳單（雲端服務仍可能按讀取或查詢量計費）；當工具背後是計費的 API，AI 每發動一次工具呼叫，就是 Server 代替你向 API 發出請求，一次呼叫可能對應一次或多次端點請求，計費按該服務的單位規則走。Ahrefs 就是這一類，官方文件寫明第三方應用代替你呼叫時，消耗的是與直接使用 API 同一份每月單位額度（見Ahrefs MCP 官方文件），站上Ahrefs MCP 完整教學有逐項拆解。模型這一側，工具定義會進到模型的脈絡裡，以 API 計價的實作每一輪都要付錢，這筆帳通常被完全忽略，後面我會逐層拆開給你看。

三條路線的費用、速度與維護對照

一個常見的誤判，是把這張表當成三選一的單次決定。它更適合當成一條演進路徑來讀：先手動查一陣子，確認哪些問題值得反覆問；再接上 MCP 用對話探索，找出值得固定下來的指標與篩選條件；等查詢內容穩定、每天都要跑，才把它寫成 API 排程。當然，需求一開始就明確、規格已經固定的團隊，直接寫 API 也是正解；跳過探索的風險只是在還不知道該問什麼的時候，就把問題寫死了。

OpenAPI、MCP、Function Calling 各自站在哪一層

成本釐清之後，再回答一個分工問題，因為這三個名詞常被攪在一起講。以 Ahrefs 這類對外開放 API 的 SaaS 服務來說，把資料送進模型最常見的是一個四層堆疊，每層各司其職：

1. 資料與服務層：資料庫、報表系統、SaaS 服務本身。資料的真相在這裡，其他層都只是取用它的不同方式。
2. API 層：服務對外開放的 HTTP 端點，這類端點常以 OpenAPI 規格描述有哪些端點、參數長什麼、回傳什麼。這層服務的對象是程式與開發者。
3. MCP 層：把工具用統一格式描述給 AI 看。規格裡每個工具定義就是名稱、描述，加上以 JSON Schema 表達的參數結構（見規格的 Tools 章節），並標準化列舉與呼叫的流程。這層服務的對象是 Host 與模型。
4. Function Calling 層：模型輸出結構化呼叫請求的格式，就是前面章節講過的那個「引擎」。Host 常把 MCP 工具包成這個格式餵給模型，兩層是接起來用的。

看懂這個分層，也要先知道它的邊界：四層堆疊描述的是「服務先有 API、再往上包 MCP」這種常見形態，不是 MCP 的必要條件。規格並不要求工具底下必須有 HTTP API，工具可以直接讀本機檔案、查公司內部資料庫，或純粹執行一段計算，本文前面看過的檔案系統 Server 就是沒有 API 層的例子。在這個邊界內，幾個常見的困惑就解開了。OpenAPI 與 MCP 不是競爭關係而是分工：OpenAPI 把端點描述給程式讀，MCP 把工具描述給 AI 用；服務商先用 OpenAPI 把 API 定義清楚，再於其上包一層 MCP Server，是很常見的堆疊順序，Ahrefs 就同時提供這兩層。你也能看懂各種「從 OpenAPI 規格自動生成 MCP Server」的工具在做什麼：它們把第二層的描述翻譯成第三層的描述，省掉手寫，但翻譯品質仍取決於來源規格寫得多清楚，規格含糊的 API 生成出來的工具描述一樣含糊。

Function Calling 在這個堆疊裡的位置也清楚了：它是最靠近模型的那一層，決定模型怎麼開口要工具；MCP 決定工具怎麼被發現、被傳遞；OpenAPI 決定底下的端點怎麼被描述。三層可以同時存在、各做各的事，討論「MCP 會不會取代 API」時真正的答案也在這裡：堆疊裡的每一層都不取代其他層，它們只是把不同的問題分開解決。

模型側的隱形成本：token 逐層拆解

MCP 的費用帳要算兩邊。資料側的單位消耗前面講過了，模型側的 token 消耗才是多數人沒預期到的部分，因為它不出現在資料服務的帳單上，而是出現在 AI 平台的帳單上。先界定計價場景：下面這筆帳是以 API 計價、每輪重送完整脈絡的實作來算的，Claude 的 Messages API 屬於這一類；用訂閱制介面的人看不到逐 token 的帳單，但資源消耗的邏輯是同一套。模型供應商把這筆帳寫得很白，以 Claude 的工具使用文件為例：計價的輸入 token 除了對話本身，還包括 tools 參數裡的工具名稱、描述與 schema，來回往返的 tool_use 與 tool_result 區塊；而且只要請求裡帶了工具，API 會自動附加一段啟用工具用的系統提示，這段提示依模型與工具選擇模式加收，多數模型落在兩百多到八百出頭 tokens。

把這份帳單套回 MCP 的實際流程，每一項都對得上：

1. 連線與列舉：Host 連上 Server 後列出工具，每個工具的描述與參數 schema 進入模型的脈絡，之後每一輪請求都計一次輸入 token（Host 若支援按需載入工具的機制，像後面會談到的工具搜尋，可以壓低這層）。一個大型服務拆出幾十個工具，等於每輪對話都背著一份固定的工具型錄在跑。
2. 模型決定呼叫：模型產生 tool_use 區塊，附帶參數，這是輸出 token。
3. 結果回傳：Server 的回應以 tool_result 進入對話歷史，多輪查詢不斷累積。資料量大的報表查詢，這是成長最快的一層，也是 context 視窗被吃滿的主要原因。
4. 工具啟用的固定開銷：如前述的系統提示，按模型加收數百 token，與你實際用了幾個工具無關。

拿一個典型情境走一遍，這筆帳會更具體。你在對話裡問一個需要查三家競品、再各自拉關鍵字的問題：模型先讀完工具清單，接著第一輪呼叫查第一家的資料，結果進歷史；第二家、第三家接著疊上去；你看了表格再追問其中一欄的細節，模型帶著前面全部的歷史再跑一輪。脈絡像滾雪球，前面每一輪的工具定義與回傳結果，後面每一輪都要重讀一次，費用也跟著重算一次。對話越長、報表越大，這個複利效應越明顯，這是把制式查詢搬回 API 的最強理由：排程腳本每輪只帶必要的參數，不背歷史。

減輕這個負擔，各平台有各的解法。重複且結構穩定的輸入，例如每輪都一模一樣的系統提示與工具定義，部分平台提供快取計價，以較低的費率處理重讀的部分，適用條件與折扣依平台而異（Claude 的提示快取文件有完整說明）。你自己能控制的則是結構面的紀律：一次對話收斂在一個主題上，跨主題就開新對話，讓歷史自然歸零；查詢明講日期範圍與筆數上限，不讓模型替你決定要撈多少；單位成本高的欄位，問的時候就指名只要核心指標。

這也是為什麼工具數量的管理會變成 MCP 的實務課題。服務商端已經在適應：Ahrefs 的 MCP 連線允許用參數只開放特定工具群組，用較小的清單換較低的脈絡負擔。模型端也在演進，Claude 的 API 就提供工具搜尋機制，在支援的模型與設定下讓代理按需找到並載入工具，而不是一次把全部工具塞進脈絡；你用的連接器吃不吃得到這類能力，取決於 Host 的實作。你在自己工作流裡能做的三件事更簡單：連接器只開要用的、用完就關；對話查詢控制回傳欄位與筆數，要深入再追問第二層；確定每天都要跑的制式查詢，讓它畢業到 API 排程，把對話留給真正的探索。

一套可以照做的選用判斷

把前面所有線索收斂成一套判斷。先做兩個盤點：資料來源開不開放 API、有沒有現成或可自建的 MCP Server，缺哪個就先劃掉哪條路（兩個都缺，手動查詢就是唯一選項）；方案權限與額度也一併確認。盤點完再依序問三個問題：

1. 頻率有多高？一年查幾次，手動查詢匯出就夠，任何工程投入都不划算。每週都有臨時的、組合式的問題，MCP 的對話彈性開始回本。每天制式跑的報表，API 的口徑穩定、可排程，加上省掉模型 token 這層開銷，長期帳最划算。
2. 誰要操作？查詢的人不寫程式，對話介面等於把查詢能力直接交到使用者手上，這是 MCP 最實在的價值。操作者是工程與資料管線，API 的可控性與可測性更重要。
3. 口徑要多穩？要進月報給主管簽核的數字，用固定程式產生，來源、時間範圍與計算方式才有辦法複查。還在探索階段的問題，讓 AI 幫你換角度問，願意接受每次結果略有出入。

三個問題也可以反過來用：當你發現自己開始嫌手動查太慢，就是評估 MCP 的訊號；當你發現對話裡有幾句查詢每天都會再問一次，就是該把它固化成 API 的訊號。工具路線的切換不需要一次到位，沿著需求強度升級，成本結構自然會站在你這邊。

從對話畢業到 API，該帶走的不是那句提示詞，而是四件事：查詢目標、需要的欄位、日期範圍、篩選條件。這四件事在對話裡是靠模型每次重新理解，搬進程式後就是固定的請求參數，口徑從此不漂移。資料服務有提供規格的話，搬運的摩擦又更低：以 OpenAPI 描述的端點可以直接餵給程式碼產生器，報表介面有查詢匯出按鈕的，把它當翻譯機用，條件在介面上調定再複製成請求。搬移完成後，對話不是被淘汰，而是退回它最擅長的位置：處理下一個還沒被定義清楚的問題。

兩種傳輸方式：從你電腦到雲端怎麼走

講完邏輯層，來看訊號實際怎麼跑。MCP 的訊息底層統一走 JSON-RPC 2.0，也就是一種把「呼叫某個方法、帶什麼參數、回什麼結果」講清楚的訊息格式。但在這個訊息格式之上，傳輸方式有兩種，根據 Server 放在哪裡來選（見 規格的 Transports 章節）。

一個重點：傳輸方式換了，訊息內容不換。同一個 Server 邏輯，你可以本機用 stdio 快速驗證，確認沒問題再包成遠端的 Streamable HTTP 版本對外提供，上層的 Tools/Resources/Prompts 規格一模一樣。這就是分層的價值，傳輸層髒活歸傳輸層，能力定義層穩穩不動。

要補一個小歷史。早期規格裡的遠端傳輸是用「HTTP 加上 Server-Sent Events」的組合，後來在 2025 年的改版中收斂成更乾淨的 Streamable HTTP。所以你在網路上會看到一些舊文章還在講 SSE 雙通道那一套，不用太糾結，2025-11-25 與 2026-07-28 兩版正式規格走的都是 Streamable HTTP。

一次連線的完整旅程：從握手到呼叫怎麼發生

到這裡你腦袋裡可能還是一張靜態的架構圖。我把它變成一段動態流程給你看，你就會懂為什麼 MCP 能做到「一個 Server、所有 Host 通用」。

一條 MCP 連線從無到有（以下按 2025-11-25 版的流程走），大概經歷這幾個階段，底層全部是 JSON-RPC 2.0 的訊息往返：

1. 握手（initialize）：Client 連上 Server 後，先遞出一份自我介紹，包含它想用的協定版本、它自己具備哪些能力、以及它是誰（Client 資訊）。Server 回一份對稱的履歷：它支援的協定版本、它提供哪些能力、它是什麼 Server。
2. 確認（initialized）：Client 確認沒問題，回一個通知，握手完成。雙方這時候都知道對方是誰、能做什麼。
3. 能力協商：根據剛剛交換的能力清單，雙方各自知道「對方有沒有支援 Tools、Resources、Prompts、Sampling、Logging」這些東西。沒有宣告的，就不會被當成可用。
4. 列舉（list）：Client 透過 tools/list、resources/list、prompts/list 把 Server 對外開放的項目全部拉出來。Host 再把這些選項呈現給模型或使用者。
5. 呼叫（call）：模型判斷需要某個工具時，Client 發出 tools/call，帶著工具名稱與參數。Server 執行後回傳結果或錯誤訊息。
6. 通知與更新：資源類能力還支援訂閱，當資料有變動，Server 可以主動通知 Client，而不必讓模型反覆輪詢。
7. 結束：工作完成或使用者關閉連線，雙方收尾，行程結束或連線斷開。

這整段流程裡，最值得你記住的是「自我描述」這四個字。Host 不必把任何 Server 的功能寫死在程式碼裡，它是在連線當下，透過握手和列舉，動態問出對方提供什麼。這就是為什麼一個寫好的 Server 可以被任何相容的 Host 直接使用：雙方靠協定自我介紹，不需要事先認識。

換個比喻：傳統整合像相親前雙方家長把對方祖宗八代查清楚才敢見面；MCP 像一場自我介紹會，雙方當場報上能耐、能配合就配合，搭不上就客氣道別，下次再來。彈性高、成本低，這種動態發現的設計，是 MCP 能把 N×M 壓成 N 加 M 的真正機制。

還有一個小細節：協定版本的交換在握手階段就完成。這代表當規格演進（例如從舊版走到 2025-11-25 版），新舊 Client 與 Server 可以在握手時協調出一個雙方都能接受的版本，不會一言不合就當機。版本相容性是被設計進協定的，不是靠運氣。這對企業導入很關鍵，你可以分批升級，不用全網同時切換。不過 2026-07-28 版把這套握手整個拿掉了：協定走向無狀態，initialize 與 initialized 不再存在，協定版本與 Client 端能力改由每個請求自行攜帶，Server 端的版本、能力與身分則改由 server/discover 這個新的呼叫一次公告。這篇的流程以 2025-11-25 版為準，讀官方文件時記得對照版本，別把兩套流程混在一起。

兩個進階能力：Sampling 與 Roots，雙雙轉入棄用

除了 Tools、Resources 與 Prompts，Sampling 與 Roots 是兩個常被拿出來討論的進階能力，但 2026-07-28 版已將兩者連同 Logging 一起列入棄用流程：過渡期間仍可運作，新的實作不應再依賴。以下說明它們的原始設計，讀的時候把這個時空背景放進去。

Sampling：Server 反過來請 AI 做事

前面講的都是 Client 呼叫 Server。Sampling 則允許 Server 在 Client 宣告支援時，請求 Host 端的模型協助生成；Host 可以拒絕、修改或要求使用者確認，並不是 Server 可直接支配模型。

舉個例子。你寫一個「分析程式碼倉庫」的 MCP Server，它跑一堆規則檢查、抓出可疑段落之後，可以透過 Sampling 把這些段落丟回去給 Host 的 AI，請 AI 寫一段「這段為什麼可能出問題」的解釋。Server 本身不用綁 API Key、不用自己養模型，直接借 Host 已經登入、已經授權的 AI 來用。

Sampling 會把外部 Server 提供的脈絡帶回模型，因而需要 Host 清楚揭露請求內容、保留使用者拒絕或修改的能力，並依風險設定逐次或分級確認。具體互動仍以 Host 實作與規格版本為準。

Roots：範圍提示，不是存取控制

Roots 讓 Client 向 Server 提供建議的檔案系統範圍，幫助 Server 理解工作脈絡。它是 advisory scope，不是安全沙盒；惡意或錯誤的 Server 不會因為收到 Roots 就失去存取其他路徑的能力。

Roots 已被 2026-07-28 版正式列入棄用，理由之一正是它無法強制執行存取邊界。真正的限制要用作業系統權限、容器、工作目錄白名單與網路政策落實。

Sampling 說明 MCP 不只支援單向工具呼叫；它與 Roots 雙雙轉入棄用，也提醒我們協定還在汰換自己的設計，範圍提示不能取代可強制執行的安全邊界。評估能力時要以實際規格版本為準。

安全這關怎麼過？MCP 的信任邊界與三大風險

講到這裡你應該有感覺：當 AI 可以直接讀你的檔案、動你的資料庫、甚至借你的 AI 做事，安全性就已經是能不能上線的硬門檻，沒辦法當成「之後再說」的附錄。規格本身也把這層講得很重（見 Security and Trust & Safety 章節）。

我把實務上最該盯的三個風險整理成表：

規格強調使用者同意、資料隱私與工具安全，但最小權限、人在迴路、稽核紀錄等控制仍要由 Host、Server 與部署環境落實。不要把安全建議誤讀成協定已自動提供的保證。

基本紀律是：只安裝來源、版本與維護紀錄可查的 Server。即使文件完整，也應先在不含真實資料的環境檢查程式碼、相依套件、權限與對外連線，再決定是否接進主流程。

遠端 Server 要使用符合規格與部署需求的認證、TLS、權限管控與憑證保存。本機 stdio 只代表傳輸通道在本機；被啟動的程式仍可能讀取檔案、環境變數或主動連上網路，因此不能當成天然安全。

MCP 生態現況：從一家開源到整個產業跟進

協定規格再漂亮，沒人生態也是白搭。這部分我簡單交代 MCP 從發布到現在的幾個關鍵發展，讓你知道它現在到底站得多穩。

時間軸大致是這樣：2024 年 11 月 Anthropic 把 MCP 開源，同時釋出 TypeScript 與 Python 兩套官方 SDK，加上一批官方範例 Server（檔案系統、Git、PostgreSQL、Slack、Google Drive 這類常見資料來源）。這個起手式很關鍵，它不是只丟一份文件要大家自己看，而是直接給你鏟子、給你範例，降低實作門檻。

接下來這一年，社群快速把 SDK 補齊到十幾種語言，Java、Kotlin、C#、Go、Ruby、Rust、Swift 都有人貢獻。Server 端更是爆發：官方範例加社群自製，從熱門生產力工具的整合到資料庫、監控、雲端服務，數量快速累積。設計工具也加入這波，Figma 為 Dev Mode 提供官方 MCP server，讓 AI 寫程式工具直接讀設計稿，這條應用路線可參考Figma 的 AI 設計工具。搜尋資料這端也有官方實例：SerpApi 提供託管端點的 MCP server，讓 AI 助手用既有訂閱額度查搜尋結果頁，站上SerpApi 的 MCP 接法有逐步說明。為了解決「Server 太多找不到」的問題，2025 年陸續出現 Server 目錄與註冊服務，讓你可以像翻型錄一樣挑選。

MCP Host 最初以 Claude Desktop 與 Claude Code 為主，2025 年起陸續有其他 AI 客戶端加入支援。共用協定能降低為不同 Host 重寫整套整合的成本，但各 Host 支援的傳輸方式、認證、權限與功能仍可能不同，不能假設「寫一次就全部通用」。除了商用客戶端，支援 MCP 的 Hermes Agent這類開源框架也可用來測試 Server 在不同環境中的行為。

治理面在 2025 年 12 月出現重要變化：Anthropic 將 MCP 捐贈給 Linux Foundation 旗下 AAIF。規格、版本與提案流程仍公開，但開放治理不代表未來一定相容或沒有供應鏈風險，企業仍要評估版本政策與維護責任。

我把生態現況濃縮成一張快照：

MCP 已有多種 SDK、Server 與 Host 實作，值得納入整合評估；是否適合正式環境，仍要看需要的能力、版本相容、安全模型與維護成本。想把它放進生成式 AI 的脈絡，可以搭配生成式 AI 全方位指南；想理解模型為什麼需要外部連接，則可讀LLM 大型語言模型入門。

三個最常見的誤解，一次說清楚

我帶不少人入門過 MCP，發現有三個誤會幾乎人人都會踩。在收尾前我把它們一次拆乾淨，你才不會帶著錯誤認知離開這篇。

誤解一：MCP 是 Anthropic 的私有協定

MCP 最初由 Anthropic 公開，但已在 2025 年 12 月捐贈給 Linux Foundation 旗下 AAIF。規格公開、多家客戶端實作，這與某一家公司的私有 API 不同；開放標準仍然需要清楚的治理與相容性流程。

誤解二：接了 MCP 就等於安全

這個誤解最危險。MCP 規範了部分認證與互動流程，但最小權限、使用者確認和資料隔離仍要由 Host、Server 與部署環境實作；光是支援協定不會自動形成安全邊界。鎖裝在高級防盜門上，你不上鎖，門一推就開。前面講的三大風險（提示注入、資料外洩、行為漂移）不會因為你用了 MCP 就自動消失，反而因為 AI 直接拿到了對資料的行動能力，需要你比以前更認真看待權限。把 MCP 當成安全的護身符，是踩向大坑的第一步。

誤解三：MCP 會取代 API

聽到「統一介面」就以為 API 要走入歷史，這也是過度延伸。MCP 不是要消滅既有的 API 或資料來源，它是在它們之上蓋一層標準化的描述與呼叫規格。底層那個資料庫、那個 SaaS、那個內部系統，還是用原本的方式提供資料；MCP Server 只是替它們穿上統一制服，讓 AI 認得、會用。換句話說，API 是食材供應商，MCP 是把食材統一擺盤、貼上標籤的那層流程。兩者是疊加，不是取代。

為什麼做 SEO 和內容的人也該懂 MCP

即使不寫程式，理解 MCP 仍有助於評估 AI 工作流與資料權限。不過，先把它與搜尋引擎最佳化的邊界畫清楚。

MCP 可讓相容的 AI 應用在授權後查詢資料或呼叫服務，因此可能參與代理型工作流。它不是唯一整合方式，也不是 Googlebot、Bingbot 或 AI 搜尋抓取公開網站所必須支援的協定。

對內容與 SEO 團隊而言，MCP 的直接用途比較像內部營運整合，例如讓已授權的工具查詢產品目錄、內容庫或報表。代理型 SEO 工具與這類內部整合之間的取捨，可以進一步看Ahrefs Agent A 與 MCP 怎麼選的分析。公開網站仍應先確保可抓取、可索引、內容準確且結構清楚。Google 對 AI 搜尋功能也明確表示，不需要額外的 AI 專用 Schema 或特殊檔案；一般搜尋資格仍是基礎。想了解代理型瀏覽，可延伸閱讀Agentic Browsing 是什麼。

可以把相關工作拆成三層：

1. 公開搜尋層：網站維持正常抓取、索引、內部連結與可驗證內容。這一層不需要 MCP，可以從Grounding 介紹理解模型如何把回答連到來源。
2. 授權資料層：若 AI 應用需要查即時庫存、方案或內部知識庫，可評估 API 或 MCP Server。這是產品整合，不是搜尋排名技巧，且必須設計認證與最小權限。
3. 內部工作流層：內容盤點、報表查詢與發布前檢查可透過 MCP 串接，但高風險動作仍要保留人工確認與稽核。

不必為了跟風就寫 Server。先問清楚資料是公開給搜尋引擎、只供內部人員使用，還是要提供給已授權的外部 AI 應用，再決定使用網頁、API 或 MCP。想把這條線延伸到代理型應用，可參考AI Agent 完整入門。

我把「還沒想 MCP」和「想過 MCP」兩種心態擺在一起，你就會看到差距：

內容團隊需要做的是定義哪些資料可以公開、哪些只能授權查詢，以及資料更新與責任歸屬。這些答案確認後，工程團隊才有理由評估 MCP，而不是先做一個沒人治理的 Server。

新手不寫程式也能起手：三個今天就能做的動作

講了一堆道理，不動手等於沒學。我給你三個不用寫一行程式、今天就能體驗 MCP 的起點，由淺到深。

第一步：在 Claude Desktop 裝一個現成的 MCP Server

Claude Desktop 是目前最容易體驗 MCP 的 Host 之一，設定檔裡加一段設定，就能掛上社群已經做好的 Server（例如檔案系統、Google Drive、GitHub）。掛上去之後，你在對話裡問「幫我找這個資料夾裡所有關於某主題的筆記」，它就真的去翻你的檔案。對 MCP 的初體驗，我強烈建議從這裡開始。先把Claude Desktop 新手入門過一遍，再回頭掛 Server，流程會順很多。

第二步：用 Claude Code 體驗「AI 替你操作環境」

進階一點，試 Claude Code。它本來就是設計來在終端機裡替你動手做事的，掛上 MCP Server 之後，能力範圍會再往外擴。我自己最常用的就是拿它搭配一些資料類 Server，讓 AI 直接幫我翻資料、整理脈絡、產出草稿，省下大量複製貼上的工夫。如果你對「AI 真的動手幫你操作環境」這件事有興趣，Claude Code 中文教學是很好的下一步。對命令列還有點陌生的人，先補一下CLI 入門教學，後面的路會好走很多。

第三步：看一個真實案例，想像你的網站怎麼接

想看 MCP 實際落地長什麼樣子，我推薦直接研究一個有完整脈絡的案例。我們站上有一篇Claude Code 搭配 WordPress 透過 MCP 打造 AI 驅動的內容流程，它把「AI 經由 MCP 接上 WordPress」整個工作流走一遍，看完你就會有具體畫面：原來所謂「AI 標準化地消費你的資料」，在真實網站上就是長這樣。把這個畫面套到自己的網站或內容庫上問一遍，你會看到一堆新的優化點。設計端也有對應的案例，Figma 設計稿轉網頁的 MCP 工作流把同一套協定接到設計稿這種資料來源上，對照著看會更具體。

資料源不必從付費服務開始。Keyword Tool 官方提供免帳號的 MCP 端點，把 Google 與 Bing 的自動完成關鍵字建議接進 Claude，每小時 60 次、每天 120 次的免費額度足夠做完一輪長尾字探索，Keyword Tool MCP 免費關鍵字研究就是這條路的完整走法。

把這篇收進行動裡：一張行動清單

讀完不是重點，動手才是。我幫你把下一步濃縮成四件可以排進行事曆的事：

1. 本週：裝一個 MCP Server。挑一個你查得到來源、看得到維護紀錄的現成 Server，掛到你慣用的 Host 上跑一次。親手跑過一遍，比看十篇文章都有感。
2. 下週：做一次安全健檢。回頭看你現在已經授權過的 AI 工具與整合，用前面那三大風險（提示注入、資料外洩、行為漂移）照一次。發現來路不明的，先收掉權限。
3. 這個月：盤點資料用途。把公開網頁、內部資料與可授權查詢的資料分開，確認其中哪些真的需要 API 或 MCP；不要把部署 MCP 當成 SEO 待辦。
4. 持續：追規格更新。MCP 還在快速演進，2026-07-28 版連握手流程都改了，之後也絕對不是終點。定期回 modelcontextprotocol.io 看一眼有沒有新章節、新原則，比追任何一個工具的版本號都值得。

MCP 真正的影響，不在它讓 AI 多接了幾個工具，而在它把「AI 怎麼接觸外部世界」這件原本各自為政的事，收斂成一套共通標準。標準一旦成形，創新就會往應用層爆發。你現在花一個下午把它搞懂，等於提前買好了下一波 AI 應用浪潮的入場券。

搜尋與 AI 應用都在演進，但沒有證據顯示先部署 MCP 就會取得 SEO 紅利。真正值得提早做的，是整理資料權限、建立可靠的更新流程，並用實際使用情境驗證整合價值。

技術細節會變，資料是否準確、可治理、能在正確授權下被使用，才是長期原則。把 MCP 當成一次盤點契機：哪些內容應公開給搜尋引擎，哪些資料只能供內部使用，哪些服務值得提供可呼叫介面？答案比追求「接了幾條管線」更重要。

等你哪天把自己的第一個 MCP Server 跑起來，回來這裡再看一次這篇，你會發現那些看似很工程的名詞，其實都在講一件很樸素的事：讓 AI 像插上插頭一樣，順利地拿到它需要的電。而你要做的，就是確保那個插座，是你信任的規格。