MCP 是什麼？新手也能看懂的 Model Context Protocol 入門指南 | 白話文商學院
MCP（Model Context Protocol，模型上下文協議）是一套讓 AI 應用用標準方式連接外部資料、工具與工作流程的開放協議，2024 年 11 月由 Anthrop…
MCP（Model Context Protocol，模型上下文協議）是一套讓 AI 應用用標準方式連接外部資料、工具與工作流程的開放協議，2024 年 11 月由 Anthropic 公開推出，最新規格版本為 2025-11-25（規格與文件公開於 modelcontextprotocol.io）[來源：〈Model Context Protocol 規格與文件〉〈https://modelcontextprotocol.io/〉〈2025〉]。它的核心價值落在整合工程這一端：把「AI 接上真實系統」這件本來要逐對客製的工作，收斂成一套統一的連接方式，根據 Anthropic 在 2024 年 11 月發布時的說明，可把開發端的整合成本從理論上的 N×M 種壓到接近 N+M。
重點先看：MCP 真正解的是開發端整合地獄，跟模型端能力上限無關。它的價值與最大風險同源：這是第一次有標準方式讓 AI 讀你的資料庫、CRM、信箱，所以每多開一格權限，就多一格需要盯著的破口，這點對應到規格文件裡 Security and Trust & Safety 章節的提醒 [來源：〈Model Context Protocol 規格 2025-11-25 Security and Trust & Safety 章節〉〈https://modelcontextprotocol.io/specification〉〈2025〉]。
MCP 的定位：連接層，不是模型也不是外掛
MCP 本身既不是模型，也不是單一外掛，更不屬於某家公司的私有功能。它讓 AI 可以走出對話框，去讀資料、用工具、執行任務，這是 代理式搜尋與資訊代理 興起後必然會長出來的基礎建設，前提是先掌握 生成式 AI 的原理與應用場景 與 Token 與 LLM 運作 的基本概念。
最接近的比喻是 USB-C：不同設備用同一種接口接螢幕、硬碟、充電器，不同 大型語言模型 應用則用同一套標準接資料庫、檔案、API、企業系統與工作流程。比喻停在這裡，因為接上電源和接上你的客戶資料庫，風險完全不是同一回事。
具體場景更能看出這條鏈路。AI 原本只能回答「我不知道你的行事曆」，但透過 MCP 連上 Google Calendar，它就能在你授權後讀行程、整理今天的會議、甚至搭配待辦工具產出任務清單。再往內部走，公司建立一個 MCP Server，讓 AI 在權限範圍內查 Notion、Google Drive 或內部知識庫，就能回答貼近公司現況的問題。這裡的關鍵在於 AI 第一次能「連接真實世界」，至於模型本身有沒有變聰明，反倒是次要問題。
從 Anthropic 推出到捐給基金會：MCP 變成業界標準的轉折
MCP 最早由 Anthropic 在 2024 年 11 月公開推出，Anthropic 是 Claude 這套 AI 助理 背後的公司。推出時它被定位為連接 AI 助理與資料所在系統的新標準，涵蓋內容資料庫、商業工具與開發環境，一開始主要用在 Claude Desktop、Claude Code 與資料連接場景，根據 Anthropic 在 2024 年 11 月發布 Introducing the Model Context Protocol 時的公開公告。
真正讓它從「Claude 家的東西」變成「業界共通標準」的轉折，發生在 2025 年 12 月。Anthropic 把 MCP 捐給 Linux Foundation 旗下的 Agentic AI Foundation（AAIF），讓它朝開放、中立、社群治理的方向發展，避免被貼上單一公司私有功能的標籤，這對應 Anthropic 2025 年 12 月公開的 donating the Model Context Protocol 公告。這一步的意涵很實際：一旦變成基金會治理的開放標準，OpenAI、Google、各家 IDE 與 SaaS 廠商接進來的政治阻力就小很多。
會突然熱門，底層原因是 AI Agent 時代工具整合需求爆發。當 AI Agent 運作原理與組成 從「問答」走向「執行任務」，業界需要一套共通的連接協議，而 MCP 是目前呼聲最高的選項。想完整理解這波趨勢，可以先讀 AI Agent 從運作原理到自動化代理的完整解析。這不代表它已經一統江湖，規格仍在演進，但方向已經清楚：它正在變成基礎建設，逐漸脫離某個產品的外掛功能定位，也讓 llms.txt 給 AI 看的檔案 這類「讓 AI 讀懂你的網站」的機制有了更標準的對接方式。
MCP 解的結構性問題：N×M 整合地獄
大型語言模型有三個天生限制：不知道最新資訊、不知道你的私有資料、不能自己操作真實世界的軟體。Google Cloud 對 MCP 的中文介紹也點出，LLM 的知識停留在訓練時間點，且缺乏與外界互動的能力，MCP 則是讓模型與外部資料、應用程式和服務溝通的標準化方式，相關說明收錄在 Google Cloud「What is Model Context Protocol」介紹頁面。
過去要解這三個限制，開發者得替每個 AI 應用客製串接每個工具。要連 Google Drive 寫一套、連 Slack 再寫一套、連 Postgres 又寫一套，換一個 AI 產品還要再來一遍。這就是業界說的 N×M 問題：N 個 AI 應用乘上 M 個外部工具，理論上會產生 N×M 種整合需求。問題不在任何一條連線多難，而在數量爆炸，這正是 Anthropic 發布 MCP 時點名的結構性問題。
換個角度想，MCP 解的就是這件結構性的事。把外部工具或資料源包裝成 MCP Server，支援 MCP 的 AI 應用就能用標準方式連上去，整合成本從 N×M 壓到接近 N+M。這是它存在的結構性理由，不是行銷話術。常見的誤解是把 MCP 框架成「讓 AI 變聰明」，這框架其實錯了，真正該看的是整合成本與互通性，這也是它跟 RAG 檢索增強生成機制、Prompt 提示詞設計原則 走向不同戰場的原因。
| 整合方式 | 開發成本 | 互通性 | 適合場景 |
|---|---|---|---|
| 逐對客製串接 | N×M，隨工具數指數成長 | 低，每條各自為政 | 少量、穩定的固定連線 |
| Function Calling（單一模型內） | 中等，但綁特定模型 | 低，跨模型難搬 | 單一產品內部工具呼叫 |
| MCP 標準協議 | N+M，寫一次到處連 | 高，跨 AI 應用通用 | 多 AI 應用、多工具、需要互通 |
這套成本結構的紅利，主要落在開發端與企業 IT 這一側；一般使用者拿到的是「AI 變得更能做事」這個結果，至於便利背後的整合工程，並不需要看見。
用具體數字感受 N×M 與 N+M 的差距會更清楚。假設一家公司內部有 3 套主力 AI 應用（客服助理、內部知識搜尋、程式開發助手），想連接 8 個外部系統（CRM、ERP、Postgres、Google Drive、Notion、Slack、GitHub、Jira）。走逐對客製路線，理論上要處理 3 乘以 8 共 24 條獨立連線，每一條都要單獨寫驗證、單獨處理錯誤、單獨做權限，其中任何一條壞掉都得回頭找原作者修。改走 MCP 路線，每個外部系統包成 1 個 MCP Server，共 8 個 Server，3 套 AI 應用各自用標準方式接上去，整合工作降到 3 加 8 共 11 個單元。連線數從 24 降到 11，且每個 Server 寫一次就能被 3 套應用共用，後續新增第 4 套 AI 應用時不必再碰 Server 端。這正是 N+M 結構在真實 IT 環境裡的實際意義。
把視野再拉大一點，這套壓低成本的效果會隨生態成熟而放大。早期只有 Anthropic 一家產品支援 MCP 時，整合者能省的工有限；當 OpenAI、Google、各家 IDE 與主流 SaaS 陸續接進同一套協議後，一個包好的 MCP Server 能被接連上的 AI 應用數量持續增加，寫一次的重用價值跟著墊高。換句話說，協議被採用的範圍越廣，每一個 Server 的投資報酬率越高，這也是把規格捐給基金會、走向中立治理在工程經濟上真正划算的原因。決策者若還在觀望要不要投入，值得把「協議採用率」當成判斷指標，而不單看某一時點的功能成熟度。
MCP 的架構：Host、Client、Server 三個角色各做什麼
MCP 架構只有三個角色，新手先記住這三個就夠：Host、Client、Server。三者之間用 JSON-RPC 2.0 訊息溝通，這是 MCP 2025-11-25 規格明定的傳輸方式 [來源：〈Model Context Protocol Specification 2025-11-25〉〈https://modelcontextprotocol.io/specification〉〈2025〉]。架構本身不複雜，複雜的是每個角色背後的權限與信任問題。
Host：你正在用的 AI 應用
Host 就是 AI 的主要使用介面，使用者輸入需求的地方。例如 Claude Desktop 連接本機工具、ChatGPT 的串接方式、Cursor、VS Code、企業內部 AI 助理，都可以是 Host。你通常在 Host 裡打字提需求，例如「幫我查這個專案最近有哪些 GitHub issue 還沒處理」，Host 再決定要不要、怎麼呼叫外部工具。
Client：Host 裡負責連線的中介層
Client 是 Host 內部跟 MCP Server 溝通的元件，一般使用者幾乎看不到它。它負責處理連線、傳遞請求、取得可用工具清單、接收回傳結果。可以把 Client 想成 Host 裡的「接線生」，你不用管它怎麼運作，但要知道：它存在，代表連線與權限是可以被設計、被控管的，不是黑箱。
Server：提供資料或工具的服務端
Server 是提供資料與工具的服務端，可說是整個架構裡最關鍵、也最需要把關的角色。常見的 MCP Server 包括 Google Drive、GitHub、Postgres、Slack、Figma 等，讓 AI 讀雲端文件、查 issue、查資料庫、搜尋訊息、讀設計稿。每一個 Server 都是一個新的資料入口與攻擊面，這點後面安全段會再展開。其中 Figma AI 的 Make 與 MCP 整合應用 就是設計工具變成 MCP Server 的典型例子。
- 你在 Host 提出需求。
- AI 判斷自己需要外部資料或工具。
- Client 去問 Server 有哪些工具可用。
- 你在授權後，AI 呼叫對應工具。
- Server 執行查詢或動作，回傳結果。
- AI 把結果整理成你看得懂的答案。
這六步就是 MCP 最核心的運作方式。看起來平淡，但真正決定成敗的是第四步的「授權」與第五步的「執行」，因為一旦工具能改變真實系統，每一步都可能是資安破口。如果你對這類自動化流程有興趣，可以延伸看 Vibe Coding AI 寫程式流程 與 CLI 命令列入門與 AI 工具，這兩個場景是 MCP 最常被實際使用的地方。對 AI 驅動程式設計的完整觀念 有興趣的人，也能順著這條線把 MCP 的價值看得更清楚。
六步流程裡最容易出狀況的環節
把六步流程拆開看，最常出狀況的集中在三個環節，提前設計防線能避免它們變成破口。最敏感的是第二步「AI 判斷自己需要外部資料」：模型憑對話內容猜要不要呼叫工具、呼叫哪一個，猜錯會走向兩種極端，要嘛該查的不查、直接用過時的訓練知識回答，要嘛過度積極呼叫、把簡單問題繞一大圈。另一個出狀況的是第三步「Client 去問 Server 有哪些工具可用」，當一個 Host 同時連上很多 Server，可用工具清單變長，模型在十幾個名字相近的工具之間挑選時誤選機率上升，這也是工具命名與描述必須寫得清楚、彼此不混淆的原因。風險最高的是第五步「Server 執行查詢或動作」，若缺乏參數校驗與權限邊界，等於把整個外部系統的暴露面交給 AI 的判斷。
對應的設計原則很具體。針對誤判，可在 Host 端設計顯式觸發詞，讓使用者明確說出要查哪個系統，降低模型猜測負擔；針對工具清單膨脹，可依任務情境分組，只把相關的 Server 連上、其餘先關閉，這也是 CLI 命令列入門與 AI 工具 裡把工具按情境分層的常見做法。針對執行風險，Server 端務必做參數型別檢查、範圍限制與 dry-run 模式，讓危險動作可以先模擬再真正執行。三道防線做起來，六步流程才會從「能用」走向「敢長期用」。
Tools、Resources、Prompts 三大能力怎麼分
MCP Server 能提供的能力很多，但新手最先要分清楚的是 Tools、Resources、Prompts 三者。官方規格把三者定義為：Resources 是資料與上下文，Prompts 是任務模板，Tools 則是模型可以執行的函式或工具 [來源：〈Model Context Protocol Specification 2025-11-25〉〈https://modelcontextprotocol.io/specification〉〈2025〉]。分法不難，難的是搞清楚哪個風險最高。
我建議用風險等級來排序這三者，別只看功能列表。風險最低的是 Resources，它只讓 AI「讀」資料；中等是 Prompts，它讓任務流程穩定，本身不改變系統；風險最高的是 Tools，因為它讓 AI「做事」，例如寄信、刪檔、部署、改 CRM。決策建議很直接：先開 Resources，再謹慎評估要不要開 Tools，高風險 Tools 務必綁人工確認。
| 功能 | 本質 | 風險等級 | 典型例子 |
|---|---|---|---|
| Resources | 提供資料與上下文 | 低（唯讀） | 文件內容、資料庫 schema、Git commit history |
| Prompts | 可重用的任務模板 | 中（不改變系統） | 程式碼審查、週報、會議摘要模板 |
| Tools | 執行動作的函式 | 高（會改變系統） | 寄信、建立 issue、部署、更新資料庫 |
為什麼 Tools 最需要小心？因為它一旦被授權呼叫，就可能真的把信寄出去、把檔案刪掉、把客戶資料改了。同樣的道理也適用在 Claude Skills 任務模板 這類封裝流程的設計，能力越被封裝得方便，越容易讓人忘記背後是真實動作。想深入了解封裝流程怎麼運作，可參考 Claude Skills 從入門到打造的完整指南。公司若要把常用流程包成 Prompts，是好事，但記得區分「產出草稿」與「執行動作」兩種模板，前者風險低，後者要額外把關。
MCP 與 API、RAG、Function Calling 的層次關係
這四個名詞常被混在一起，其實分屬不同層次。API 是軟體與軟體之間溝通的底層接口；Function Calling 是模型端決定呼叫哪個函式的能力；RAG 負責檢索靜態文件補充上下文；MCP 則是協議層，把上述能力包裝成 AI 容易發現、理解與使用的標準工具箱。四者不互相取代，而是經常疊加使用。
一個簡單的比喻：API 是零件，MCP 是把零件整理成 AI 可用的工具箱，Function Calling 是模型決定拿哪一把工具，RAG 則是工具箱裡專門用來翻文件的抽屜。MCP 背後經常還是呼叫 API，所以它無意取代 API，目的只是讓 AI 應用不必每次都重新理解每個 API 的細節。這層關係跟 GEO 與 SEO 差異入門 裡「疊加而非取代」的邏輯很像。要弄懂 RAG 這個抽屜的原理，建議讀 RAG 檢索增強生成的運作機制與優勢。
| 項目 | 定位 | 擅長場景 | 誰觸發 | 會被 MCP 取代嗎 |
|---|---|---|---|---|
| API | 底層能力接口 | 程式對程式固定呼叫 | 開發者寫死 | 不會，MCP 建立在 API 之上 |
| Function Calling | 模型端呼叫能力 | 模型決定呼叫哪個函式 | 模型自己決定 | 不會，MCP 提供標準化工具描述與發現 |
| RAG | 檢索靜態文件 | 查知識庫、降低幻覺 | 系統在生成前檢索 | 不會，MCP Server 背後可用 RAG 查文件 |
| MCP | 標準化連接協議 | 多工具、跨 AI 應用互通 | Host 透過 Client 連 Server | 是協議層，疊加在上述之上 |
兩個最常被問的問題直接回答：MCP 不會取代 API，因為它很多時候就是包在 API 上面；MCP 也不會取代 RAG，因為 RAG 擅長檢索靜態文件、MCP 擅長連接即時工具與流程，兩者可以並存，例如 MCP Server 背後用 RAG 查文件，再把結果回傳給 AI。回顧一下，這四者更像一座分工清楚的工具間，各自有定位，沒有誰要搶誰的工作。而 Grounding 被 AI 引用的關鍵 與 BM25 餵給 LLM 的素材排序、TF-IDF 關鍵字權重，處理的是「內容怎麼被檢索」那一層，跟 MCP 的「工具怎麼被呼叫」是兩個戰場。
ChatGPT、Claude、Gemini 各自怎麼接 MCP
三家接 MCP 的路徑不同，但核心相同：先準備好 MCP Server，再讓 AI 應用把它加進可用工具清單。差異在於偏重的場景。ChatGPT 偏 Apps 與 API 整合，Gemini 偏 CLI 與 coding agent，Claude 則在 Claude Code、Desktop 與 Connectors 提供最直接的 MCP 路徑。使用者門檻 Claude 最低，開發者彈性 Gemini 高，SaaS 整合 ChatGPT 路徑清楚，以上整理自 OpenAI、Google 與 Anthropic 各自發布的官方開發者文件。
ChatGPT 怎麼串 MCP
ChatGPT 串 MCP 主要兩條路：一是透過 ChatGPT Apps 或 Apps SDK，把服務做成能在 ChatGPT 裡使用的 App；二是透過 OpenAI API，把 remote MCP server 當成工具接進自己的產品。一般使用者看到的多半是「連接某個 App」或「授權某個服務」；開發者則要架一個提供 HTTPS endpoint 的 remote MCP server，讓 Codex 程式助理與工具整合 或 ChatGPT 購物與 BEO 場景 在需要時呼叫對應 tool。
Gemini 怎麼串 MCP
Gemini 的 MCP 串接偏開發者與 coding agent 場景。用 Gemini CLI 時，可以在 settings.json 裡設 mcpServers，讓它啟動時連接一個或多個 MCP Server，對應做法記載於 Gemini CLI 關於 MCP servers 的官方文件。你可以把 GitHub、資料庫、文件搜尋或設計工具包成 Server，讓 Gemini 模型與使用技巧 在寫程式、查錯、整理文件時使用。若你還不熟 Gemini，先看過 Gemini AI 從新手到進階的完整攻略 會更好上手。所以在 Gemini 生態談 MCP，最好理解成「CLI 與 coding agent 的外部工具連接方式」，而不等同於網頁版的一個按鈕。
Claude 怎麼串 MCP
Claude 是最早大量推動 MCP 的產品，因此生態相對成熟。以 Claude Code 的 MCP 設定 來說，可用指令加入 remote HTTP server、本機 stdio server，或帶授權 header 的服務，並支援 local、project、user 不同層級，團隊專案還能放.mcp.json 共用同一組 Server。Claude Cowork 協作情境與 Claude Code 與 Cowork 差異也都建立在這條連接能力上。Claude Design 設計應用則示範了 MCP 怎麼把設計稿接進開發流程。想從零開始學這套工具，Claude AI 從新手到進階的使用指南 是很好的起點。
| AI 應用 | 主要路徑 | 偏重場景 | 共同前提 |
|---|---|---|---|
| ChatGPT | Apps / Apps SDK、OpenAI API 接 remote MCP server | SaaS 整合、企業助理 | 授權範圍、資料流向、日誌 |
| Gemini | Gemini CLI settings.json 設 mcpServers | coding agent、開發者工具 | 授權範圍、資料流向、日誌 |
| Claude | Claude Code 指令、Desktop、Connectors | 本機工具、團隊協作、企業 | 授權範圍、資料流向、日誌 |
不管走哪一家，共同前提都是同一件事：處理好授權範圍、資料流向與日誌。這三項做不好，換哪一家都不會安全。
MCP 的應用情境與一條判斷原則
只要 AI 需要外部資料或工具，就可能用 MCP。常見場景涵蓋個人助理、AI Coding、企業知識庫、BI、客服 CRM、行銷內容、設計開發、DevOps、研究助理與任務型 Agent。這些場景看起來差很多，本質卻一樣：AI 先取得必要上下文，再在授權範圍內協助查詢、整理、建立草稿或執行任務。例如 Claude Code 搭配 WordPress 的 MCP 應用，就是把內容管理系統接上 AI 的典型做法。
判斷原則只有一條，但非常重要：涉及寄信、付款、部署、刪除、修改客戶資料或更新正式系統的動作，必須保留人工確認。讀取公開資料風險低，能改變真實系統的動作風險高，這條線不該由 AI 自己決定要不要跨。為了方便判斷，把上述場景依風險分級來看：低風險多為唯讀或草稿，例如個人助理讀行事曆、企業知識庫查文件、研究助理查文獻、行銷讀品牌規範與 SEO 資料；中風險會產出內容或半自動運作，例如 AI Coding 讀專案與 Git history、資料分析與 BI 查報表、設計開發讀 Figma 與產品規格、客服 CRM 查客戶與訂單；高風險則直接改變真實系統，例如 DevOps 部署與監控、任務型 Agent 的付款、訂票、預約與刪除操作。
以一個想把 CRM 與 BI 報表接給內部 AI 助理的中型組織為例，常見的狀況是：起初每人各自在本機裝 stdio 版的 MCP Server 接 Postgres 與客戶資料庫，起步快、資料也不離開個人機器，但用了一段時間後，每換一個人就重跑一次安裝與權限設定，授權範圍也分散在各機器難以統一稽核。這類站點依典型表現，大約在連線規模成長到約 3 至 5 套 AI 應用、連接約 6 至 10 個外部系統時，會浮現「分組管理與集中日誌做不下去」的壓力，這時把同樣邏輯重包成 remote Server、集中部署治理，通常會比繼續堆 stdio 划算。不過要誠實點出一個常見的失敗點：一旦搬到 remote，資料實際流經的節點變多，若沒有同步把身分驗證、傳輸加密與完整呼叫日誌一次補到位，集中化的便利反而會讓單一設定疏漏的影響範圍放大，這也是為什麼前一段強調「先補治理再開高權限」是這類情境的決策主軸，而不是先比誰接的 Server 多。
企業落地的熱區，集中在接 CRM、BI、DevOps 與內部工作流程。這也是 內容行銷與 AI 應用、數位行銷與自動化整合 團隊開始關注 MCP 的原因：當 AI 能直接讀成效報表與品牌規範，產出會更貼近現況。不過企業場景也意味著更高的治理門檻，這點下一段會展開。對關注能見度的團隊來說，搭配 GEO 能見度監測工具 與 Bing AI 引用報表 一起看，才知道 AI 究竟有沒有用到你的資料與內容。行銷人若想系統化理解這條鏈路，可從 MarTech 行銷科技全景指南 切入，再用 GA4 追蹤 AI 流量的篩選器設定 與 Ahrefs 核心功能實戰教學 把數據看清楚。
新手與工程師分別怎麼開始用 MCP
新手不必寫 MCP Server，從支援 MCP 的現成 AI 工具開始就好，例如 Claude Desktop、ChatGPT Apps、Cursor、Gemini CLI 或企業內部已經設定好的 AI 工具。重點在於看懂三件事：這個工具會連哪些服務、讀哪些資料、能不能改資料，技術細節可以擺在後面。看懂這三點，比追任何 MCP Server 清單都實用。如果你選擇從 Claude Code 入手，Claude Code 新手入門的安裝設定攻略 會幫你跨過第一道門檻。
在急著把一堆 Server 接上去之前，更該先問一個反向問題：接了之後誰管權限、誰留稽核？這才是第一課。讀取公開資料風險低，一旦會讀私人文件、公司資料、API key 或資料庫，就要非常謹慎。Google AI Overviews 摘要 與 Perplexity AI 搜尋整合 這類工具的「連接」也是同樣邏輯：先看授權範圍，再看功能。
- 先用現成 MCP Server（檔案系統、GitHub、Postgres、Slack、Google Drive），觀察 AI Client 怎麼列 tools、怎麼呼叫、怎麼回傳。
- 用 MCP Inspector 測試 tools、resources、prompts 的行為與邊界。
- 從低風險功能開始自建，例如查詢資料、列文件、產摘要。
- 等權限控管、日誌、錯誤處理成熟後，再開放修改資料或執行高風險動作。
工程師想深入了解，OpenAI 提供了 Building MCP servers for ChatGPT Apps and API integrations 的官方文件，Anthropic 與 Google 也各有 Claude Code 與 Gemini CLI 的 MCP 說明，三家的開發者文件都對應到上述各自的串接路徑。工程建議一句話：先做查詢、列文件、摘要這類只讀不寫的功能，把權限、日誌、錯誤處理打磨好，再談開放修改。如果你用的是 Claude Code，Claude Code Plugins 實戰指南 能幫你把外部工具整理得更順手。AI 搜尋引擎工具比較 與 AI Agent 瀏覽網站模式 也值得順著這條線看，它們背後的「連接外部資訊」邏輯是一致的。
stdio 與 remote 兩種 MCP Server 傳輸模式的取捨
實作 MCP Server 時，最先要決定的是傳輸模式。規格目前定義的主要傳輸方式有 stdio 與 remote 兩大類：stdio 模式下，Server 是一個本機子程序，Host 啟動它、透過標準輸入輸出與它溝通；remote 模式則是把 Server 部署成一個提供 HTTP（通常搭配 SSE 或新的 Streamable HTTP）endpoint 的網路服務，Host 透過網路連過去 [來源：〈Model Context Protocol Specification 2025-11-25 Transports 章節〉〈https://modelcontextprotocol.io/specification〉〈2025〉]。兩者對應的是完全不同的部署與信任模型，選錯會讓後續治理變得極度麻煩。
stdio 適合本機、個人、開發者場景。它的優點是部署簡單，Server 直接讀本機檔案系統與本機憑證，不必開網路端口，資料不離開這台機器；缺點是難以分享，每位使用者要各自安裝、各自設定，團隊協作與企業集中管理成本較高。remote 則適合多使用者、跨團隊、SaaS 整合場景，優點是集中部署、集中治理、一份 Server 給整個團隊用，授權與日誌可以統一收在一個地方；缺點是它把 Server 暴露在網路上，必須處理身分驗證、傳輸加密、網路層防護與 rate limit，治理門檻明顯較高。簡單的判斷法是：工具只給自己用、且資料在本機，挑 stdio；工具要給多人或外部 AI 服務呼叫，挑 remote 並把治理一次做滿。
| 面向 | stdio 模式 | remote 模式 |
|---|---|---|
| 部署位置 | 本機子程序 | 獨立網路服務 |
| 資料移動範圍 | 不離開本機 | 可能跨網路、跨網域 |
| 分享與重用 | 低，各自安裝 | 高，一份給多人用 |
| 集中治理 | 困難 | 容易，授權日誌可統一 |
| 安全負擔 | 本機權限管理 | 身分驗證、加密、網路防護 |
| 典型場景 | 個人開發、本機工具 | 團隊、企業、SaaS 整合 |
選擇時還有一個常被低估的因素：遠端連線會讓資料的實際流向變得難以追蹤。一個本機 stdio Server 讀你的 Postgres，你知道資料留在哪；同一個邏輯包成 remote Server 放到雲端，AI 每次呼叫都把查詢結果傳過網路，就牽涉資料落地、跨境傳輸與第三方信任問題。企業在評估時，務必把「資料實際流經哪些節點」這一條寫進採購或自建評估清單，而不只是看功能強不強。這條資料流向的紀錄，後面安全段的完整日誌稽核會直接依賴它。
實際導入時最常碰到的卡關點與排除方向
理論講再多，落地時碰到的是具體的卡關點。下面幾項是實際導入 MCP 時最常被回報的疑難，逐一給出排除方向，方便你在踩到時有跡可循。第一個是「AI 呼叫了錯的工具」。成因通常是工具清單裡有兩個以上職責重疊、命名相近的 Server，模型在挑選時判斷失準。排除方向是合併或重新命名職責重疊的工具，並在工具描述裡明確寫出使用時機與不適用情境，讓模型的選擇有清楚依據。
- 授權後資料讀不到：多半是 Server 端的憑證或範圍設定問題，而非 MCP 本身。檢查 Server 連的是哪個帳號、那個帳號在目標系統的實際權限範圍，通常能定位。
- 回應很慢、體驗卡頓：常見於一個 Host 同時連上過多 Server，或單一工具回傳大量未經篩選的資料。對應做法是依任務分組連線、在 Server 端做分頁與摘要，避免把原始大結果直接丟回模型。
- 工具時靈時不靈：通常是上游 API 的速率限制或不穩定造成。在 Server 端加上重試、快取與明確的錯誤訊息，能讓模型遇到暫時性失敗時知道要重試或改走替代方案。
- 升級 Server 後行為改變：MCP 規格仍在演進，Server 版本更新可能調整工具簽名或回傳格式。建議為關鍵 Server 固定版本、在測試環境驗證後再升級，並保留變更紀錄。
這五個疑難有一個共同點：它們多半不是 MCP 協議本身的缺陷，而是實作細節與治理紀律的問題。把工具命名、權限範圍、版本控制、上游穩定性這些基本功做扎實，大半疑難會在發生之前就被擋掉。如果你已經踩過其中幾個，表示你的導入已經走到實戰階段，接下來的進階評估矩陣會幫你決定要不要再往高風險功能推進。
進階評估矩陣：用兩個維度判斷該不該開放某個 MCP 工具
把前面散落的判斷原則收斂成一張二維矩陣，會比記住一堆規則更實用。橫軸是「動作影響範圍」，分唯讀、產出草稿、改變真實系統三級；縱軸是「資料敏感度」，分公開資料、內部一般資料、機敏或個資三級。兩者交叉，可以把任何一個想開放給 AI 的 MCP 工具放進對應格子，並讀出對應的治理要求。這個矩陣的核心訊息很直接：影響範圍越大、資料越敏感，治理要求越高，且高敏感度資料即使只做唯讀，也不能掉以輕心。
| 資料敏感度 ＼ 動作影響 | 唯讀 | 產出草稿 | 改變真實系統 |
|---|---|---|---|
| 公開資料 | 低門檻，基本日誌 | 低門檻，產出留紀錄 | 中門檻，人工確認 |
| 內部一般資料 | 中門檻，授權範圍受限 | 中門檻，草稿不外傳 | 高門檻，人工確認加審核 |
| 機敏或個資 | 高門檻，最小欄位存取 | 高門檻，去識別化處理 | 最高門檻，多層核可 |
用矩陣走一次常見情境就能看出它的價值。讓 AI 讀公開氣象資料回答天氣，落在左上角「公開資料×唯讀」，治理負擔最低；讓 AI 讀公司內部 wiki 整理週報，落在「內部一般資料×產出草稿」，要確認草稿不會外傳到外部模型；讓 AI 直接在 CRM 裡更新客戶聯絡資訊，落在「機敏或個資×改變真實系統」，這格要求最高，需要多層核可、完整稽核，多數情況下還要保留人工把關。把每一個想開放的工具都過一次這張表，團隊對「為什麼這個工具要這樣設限」會有共通語言，爭論空間大幅縮小。
矩陣還能反過來用：當業務單位提出「能不能讓 AI 自動做某件事」時，先把這件事放進對應格子，再決定要不要做、怎麼做。落在低門檻格子的需求，可以快速放行；落在高門檻格子的需求，先把治理補到對應等級，否則寧可暫時只做到產出草稿、由人工完成最後一步。這種「先定位風險等級再決定自動化程度」的節奏，是企業把 MCP 從實驗推到正式環境的關鍵紀律。
MCP 越強越危險：安全底線與 OWASP 警告
MCP 讓 AI 能接觸外部資料並執行改變真實系統的動作，風險與能力成正比。官方規格的 Security and Trust & Safety 章節明確指出，MCP 會帶來任意資料存取與程式執行路徑，因此實作者需要謹慎處理安全與信任問題 [來源：〈Model Context Protocol Specification 2025-11-25 Security and Trust & Safety 章節〉〈https://modelcontextprotocol.io/specification〉〈2025〉]。這是規格層級的提醒，不是危言聳聽。
如果權限設計不好，MCP 可能造成資料外洩、錯誤操作、權限濫用、工具投毒、指令注入，甚至供應鏈攻擊。OWASP 已整理 MCP Top 10 風險清單，包含 model misbinding、context spoofing、prompt-state manipulation、insecure memory references、covert channel abuse 等項目，並提供 MCP Security Cheat Sheet 給實作者參考，相關清單與速查表公開於 OWASP GenAI Security 專案。提示注入風險尤其值得警惕：一個看似無害的文件內容，可能藏著誘導 AI 呼叫高權限工具的指令。
- 最小權限原則：只給 AI 完成任務需要的資料與工具權限，不多給一格。
- 高風險動作人工確認：寄信、付款、刪檔、部署、改資料庫，都該有人在迴圈裡按確認。
- 不安裝來路不明的 Server：第三方 MCP Server 是供應鏈風險的入口，來源與可信度要先查。
- 完整日誌與稽核：誰連接、讀了什麼、呼叫哪些工具、執行哪些動作，全都要留下紀錄可回溯。
這四個底線不是建議，是底線。企業導入 MCP 時，不該由業務單位自行裝外掛，IT、安全、法務與資料治理都必須參與。把 AI 接上系統卻不鎖門，等於把便利與風險同時放大。這也是為什麼 E-E-A-T 內容品質原則 與 資訊增益內容概念 這類「治理與可信度」的框架，會跟 MCP 議題越走越近：能力越開放，治理越要走在前面，而內部連結與網站架構的清楚程度，也會影響 AI 怎麼理解與使用你的內容。一份清楚的網站 Sitemap 同樣是這條治理線的基本功。
MCP 適合誰、不適合什麼情境：決策檢查表
MCP 適合需要讓 AI 讀寫真實系統的開發者、企業 IT、PM 與創業者。工程師可用在 AI Coding、自動化與 DevOps；企業 IT 用它標準化內部系統連接；PM 與創業者則可思考把產品本身變成 MCP Server，讓各種 AI Agent 安全使用。但若只是問一般知識、寫文章、做單次查詢，或組織還沒建立權限控管與資料治理，就不該急著開放高權限 MCP Server。
| 問題 | 若是「是」 |
|---|---|
| 1. 我的任務需要 AI 讀取或操作真實系統（資料庫、CRM、檔案、API）嗎？ | 是 → 可考慮 MCP |
| 2. 我需要多個 AI 應用共用同一套工具連接嗎？ | 是 → MCP 的標準化價值浮現 |
| 3. 我已經有基本的權限控管、日誌與資料分級了嗎？ | 否 → 先補治理，別急著開高權限 |
| 4. 涉及的動作中有寄信、付款、刪除、部署等高風險項目嗎？ | 是 → 務必綁人工確認 |
| 5. 我只是要問知識、寫文章、翻譯、單次查詢嗎？ | 是 → 用 API 或 RAG 即可，不需要 MCP |
一般使用者不一定要懂技術，但要關注授權範圍、資料隱私、能不能撤銷權限，以及 AI 執行重要動作前會不會讓你確認。對 PM 與創業者來說，MCP 代表一種新的產品整合方式：可以跳脫「只做一個聊天機器人」的框架，想想產品能不能本身就成為 MCP Server。例如用 Claude Code 搭建專業網站 或挑選 AI 網站建立工具來打造產品，再進一步把產品本身接上 AI；客服場景也能參考 Chatfuel Messenger Bot 教學，理解聊天機器人怎麼串接外部資料。相關的 品牌成為被推薦的答案 與 Google AI Mode 新搜尋，都是「讓你的內容與服務被 AI 找到、被 AI 使用」這條線上的議題；想再進一步，可參考 AXO AI 全搜尋體驗優化與 SEO 自學技巧。
不適合的情境也講清楚。純問答、寫作、翻譯、單次查詢，用 API 或 RAG 就夠了，硬上 MCP 只會增加複雜度與風險。組織還沒有權限控管、日誌、資料分級與安全流程時，也不該開高權限 MCP Server。MCP 是工具，不是魔法，它可以讓 AI 更有能力，也會讓錯誤操作與資安問題更有破壞力。在追 Google I/O 2026 搜尋演進 或 AI 時代 SEO 趨勢建議 裡的新名詞之前，治理基本功更值得先練好。
說到底，MCP 的價值與風險是同一件事：它第一次讓 AI 有標準方式接觸你的真實資料與系統。所以判斷要不要用，關鍵在於你的權限治理跟不跟得上，方便性只是附帶考量。最小權限、高風險動作人工確認、不安裝不明 Server、完整日誌稽核，這四件事做到了，MCP 才會是助力，否則就是破口。如果你正在評估把 AI 接進內部系統，這四條就是你的第一份檢查表。想知道 Google 對 AI 內容的看法 或 Entity SEO 實體策略 怎麼跟這波 AI 工具整合，可以順著這條線繼續往下看。想進一步讓自己的內容被 AI 優先引用，也可參考 AI 偏好內容的規劃策略。
MCP 常見問題
MCP 是誰推出的？為什麼突然變熱門？
MCP 由 Anthropic 在 2024 年 11 月公開推出，並於 2025 年 12 月捐給 Linux Foundation 旗下的 Agentic AI Foundation，轉為開放中立治理。隨 AI Agent 工具整合需求爆發，MCP 成為業界呼聲最高的共通連接標準。
MCP 有哪些安全風險？
包含資料外洩、錯誤操作、權限濫用、工具投毒、指令注入與供應鏈攻擊，OWASP 已整理 MCP Top 10 風險清單。實務上應遵守最小權限原則、高風險動作人工確認、不安裝來路不明的 Server，並保留完整日誌與稽核紀錄。
MCP 跟 Function Calling 有什麼差異？
Function Calling 是模型端決定呼叫哪個函式的能力，通常綁定單一模型；MCP 則是協議層，提供標準化的工具描述與發現機制，讓同一套工具能被不同 AI 應用共用。
新手該怎麼開始？
從支援 MCP 的現成 AI 工具開始，先看懂會連哪些服務、讀哪些資料、能不能改資料，這三件事比追任何 Server 清單都重要。