你可能在 AI 工具、開發框架或聊天軟體的設定裡看過 MCP，接著遇到一串更難的問題：MCP 到底是模型、外掛、API，還是一種 Agent？Host、Client、Server 又是哪三個角色？開一個 MCP Server 之後，AI 是不是就能安全地讀取所有資料？
先講本文的判斷：MCP，也就是 Model Context Protocol，是一套讓 AI 應用與外部系統交換脈絡與能力的開放協定。它整理了應用程式如何連接伺服器、如何發現 Tools、Resources、Prompts，以及如何交換結果；它本身不是模型，也不是自動化平台，更不會替你決定某個 Server 是否可信或某個動作是否應該被核准。
這個區分很重要。協定可以降低每個整合都重新發明連線格式的成本，但不會自動消除權限、資料品質、版本相容性與錯誤輸出的問題。你仍然要看使用中的 Host 和 Client 支援哪些版本與能力、Server 實際暴露哪些操作、帳號可以碰到什麼資料，以及結果能不能被驗收。
本文以 2026-09-12 查到的 Model Context Protocol 官方架構、Server concepts、Tools、Resources、Authorization 與 Security 文件為查證邊界。官方規格頁目前以 2026-07-28 版本為主；實作支援、產品方案、登入狀態、可用 Server 清單和資料保留方式，若沒有在你的帳號或環境中讀回，就一律視為 unknown。
文章目錄
MCP 是什麼？先分清楚協定與產品
MCP 官方解決的是哪一段問題
Model Context Protocol 官方文件把 MCP 描述成連接 AI 應用與外部系統的開放標準。外部系統可以是本機檔案、資料庫、搜尋服務、計算工具或企業內部服務。官方用 USB-C 作為類比：它提供一套共同的連接方式，但不代表所有接上的裝置都有相同功能。
用工程語言說，MCP 規範的是一段溝通契約。應用程式可以用 MCP Client 和某個 MCP Server 建立連線，讀取 Server 宣告的能力，再依照協定格式列出、呼叫或取得結果。這讓 AI 應用不必為每個資料來源都設計一套完全不同的整合流程。可以先讀 MCP 官方 What is MCP? 和 Architecture。
但「有共同協定」不等於「已經整合完成」。你的應用仍然要有能說 MCP 的 Client，外部系統也要有能提供 MCP 的 Server；兩端還要對版本、傳輸方式、驗證、能力與錯誤處理有相容的實作。官方規格能定義邊界，不能替你保證第三方程式的品質。
MCP 不是模型，也不是一個新的 AI
MCP 不會產生文字，也不會自己判斷答案。模型通常位於 Host 所管理的 AI 應用內，Host 再透過一個或多個 Client 連接外部 Server。Server 可以提供工具或資料，但它不是模型的替代品。
MCP 也不是一個自動化流程設計器。你可以把 MCP Server 接到 Agent 或 Workflow 裡，但要由哪個步驟呼叫、何時停止、哪些結果要人工確認，仍然是上層應用或 Harness 的責任。把 MCP 裝好，不會自動得到一個可靠的 Agent。
本文的工作定義與證據界線
本文使用以下工作定義：MCP 是一套描述 AI 應用與外部 Server 如何交換工具、資源、提示與相關協定訊息的標準。這是對官方文件的整理，不是說所有產品都以完全相同的 UI 或功能實作它。
接下來如果句子談到規格裡的角色和訊息，就以官方文件為依據；如果句子談到「我會怎麼導入」，那是本文的建議；如果句子談到某個產品是否支援某個 Server、某個方案是否開放遠端連線，沒有讀到當下帳號與文件就保留 unknown。這個邊界看起來保守，但少一個「應該可以」通常比多一個錯誤權限承諾實用。
Host、Client、Server：MCP 的三個角色
Host 是承載 AI 工作的應用程式
Host 是使用者實際開啟的 AI 應用程式，例如一個聊天工具、程式開發環境或研究工作台。依官方架構，Host 負責協調模型、使用者互動、權限與多個 Client 連線。Host 可以決定何時把 Server 提供的資訊交給模型，也可以在執行高風險操作前要求使用者確認。
所以不要把 Host 簡化成「瀏覽器分頁」。它可能有自己的對話狀態、模型選擇、提示流程和使用者介面。即使兩個 Host 都能連上同一個 MCP Server，它們對工具確認、資源呈現、錯誤訊息和資料保留的處理仍可能不同。
Client 是 Host 與單一 Server 之間的連線元件
Client 通常由 Host 建立，負責和一個特定 Server 溝通。官方架構說明採一個 Client 對一個 Server 的連線關係；如果一個 Host 要用三個 Server，通常就會有三個對應的 Client 連線。
Client 的責任包括協商協定版本、表達自己的能力、送出請求、接收回應和處理通知。它不是使用者看到的產品名稱，也不一定是一個獨立安裝的程式。很多產品會把 Client 包在 Host 裡，因此設定畫面只看到「新增 MCP Server」，看不到 Client 這個詞。
Server 是提供能力或資料的一端
Server 可以連到檔案系統、資料庫、第三方 API、Git 儲存庫、日曆或內部服務，並依 MCP 格式向 Client 暴露能力。官方 Server concepts 把 Tools、Resources、Prompts 視為三種核心能力，讓 Server 能提供不同性質的互動。
Server 不必等於一台遠端機器。它可以在本機程序中用標準輸入輸出溝通，也可以在遠端服務上用 HTTP 傳輸。名稱的重點是「提供 MCP 能力的一端」，不是硬體位置。
| 角色 | 主要責任 | 你要驗收的問題 |
|---|---|---|
| Host | 承載模型、對話、使用者互動與整體授權流程 | 使用者看得到什麼？誰能核准操作？ |
| Client | 連接單一 Server、協商版本、送出請求與接收結果 | 支援哪些版本、傳輸與能力？錯誤怎麼回報？ |
| Server | 提供 Tools、Resources、Prompts，並連到實際資料或服務 | 實際能讀什麼、寫什麼？輸入如何驗證？ |
這三個角色也解釋了一個常見誤會：你在 Host 裡看見一個工具名稱，不代表工具本身知道使用者的全部權限。權限可能由 Host、Client、Server、OAuth 服務和底層資料庫共同決定，必須沿著實際請求路徑讀回。
Tools、Resources、Prompts 各自負責什麼
Tools：模型可以請求執行的動作
Tools 是 Server 暴露的可執行功能，例如查詢資料、呼叫計算器、建立工單或更新某個系統。官方 Tools 規格說明，工具可以有名稱、描述、輸入 schema、輸出 schema 與錯誤回應；Host 可以把可用工具呈現給模型，由模型判斷是否提出呼叫。
工具由模型提出呼叫，不代表模型擁有無限制的執行權。官方文件建議保留人類拒絕工具呼叫的能力，並且在執行前清楚顯示輸入與作用。對讀取公開文件的工具，確認流程可以較輕；對刪除、發送、付款、發布或修改正式資料的工具，應該把人工核准當成明確的 Gate。
Resources：可被讀取的資料或內容
Resources 是 Server 提供的資料，通常有 URI，可以代表檔案、文件、資料庫紀錄或其他能被應用程式讀取的內容。Resources 比較接近「把資料提供給應用或模型參考」，不等同於執行一個動作。
官方文件把 Resources 描述為 application-driven：應用程式可以決定什麼時候讀取、怎麼整理、是否顯示給使用者。這和 Tools 的模型驅動特性不同。實際導入時，仍要檢查 Resource 的 URI 是否可能暴露敏感路徑、內容是否會隨時間變動，以及讀取結果是否需要引用或版本標記。
Prompts：可重用、由使用者選擇的提示模板
Prompts 是 Server 提供的預先定義提示或訊息模板，例如「檢視這份程式碼」、「把這批資料整理成摘要」或「針對這個資源產生問題清單」。官方 Server concepts 把 Prompts 描述為 user-controlled：使用者選擇或觸發，而不是讓模型悄悄決定要套用哪個模板。
這種區分讓責任更容易追蹤。Prompt 說明如何開始工作，Resource 提供工作所需的資料，Tool 執行需要外部副作用的動作。三者可以一起使用，但不應因為它們都出現在同一個設定頁，就把它們當成同一種權限。
| 原語 | 驅動方式 | 適合表達 | 需要注意 |
|---|---|---|---|
| Tools | 模型提出，應用或使用者可核准 | 查詢、計算、建立、更新等動作 | 輸入驗證、副作用、重試與人工確認 |
| Resources | 應用程式決定何時讀取 | 檔案、文件、紀錄與資料內容 | URI、敏感資料、內容新鮮度與引用 |
| Prompts | 使用者選擇或觸發 | 可重用的工作起始模板 | 模板來源、參數、使用者是否知道它會做什麼 |
以上是官方原語的責任整理，不是每個產品介面一定會用這三個名稱。某些 Client 可能只呈現 Tools，或把 Resources 先轉成其他上下文格式；如果產品沒有公開能力表，這種支援狀態應記為 unknown，而不是從設定畫面推論完整相容。
一次 MCP 請求如何從發現走到結果
1. 先初始化並協商能力
Client 和 Server 建立連線後，會先交換協定版本與能力資訊。能力可能包括 Server 是否能列出工具、資源或提示，Client 是否支援某些通知或其他功能。這一步的重點不是取得一張「所有功能都可用」的通行證，而是讓雙方知道接下來應該用什麼方式溝通。
若版本或能力不相容，較好的結果是早點顯示清楚錯誤，而不是在使用者按下工具後才得到一個模糊的失敗。這也是為什麼建置完成後要讀回初始化結果和能力清單，而不只看設定檔是否成功儲存。
2. 發現 Tools、Resources、Prompts
Server 可以透過對應的列出方法回報目前能力，例如 tools/list、resources/list 或 prompts/list。工具的輸入與輸出 schema 讓 Client 或模型知道該怎麼提出請求；Resource template 則可協助應用程式根據 URI 模式找到不同資料。
發現不是一次性安裝。工具清單可能因權限、登入狀態、版本或 Server 本身的動態能力而改變。官方 Tools 規格也定義工具清單變更通知的概念，因此實作不應永遠假設第一次讀到的列表就是永久狀態。
3. 模型提出呼叫，應用決定是否放行
當模型判斷某個工具有用時，Host 或 Client 會形成 tools/call 請求。這裡應該先確認使用者是否授權、輸入是否符合 schema、Server 是否仍然提供該工具，以及這個操作是否會產生副作用。
一個工具回傳成功，不代表整個任務成功。工具可能回傳空資料、部分資料、格式錯誤或帶有不可信的註解。官方安全建議包括顯示工具輸入、驗證結果、設定 timeout、保存適當的 log，並讓使用者能控制高風險操作。
4. 將結果放回可追蹤的工作脈絡
工具結果通常會回到 Host，再由 Host 決定如何提供給模型或使用者。此時最好保留來源、時間、請求參數摘要和錯誤狀態；若資料敏感，則要在 log 和顯示層做遮蔽。
對研究或內容工作而言，最少要能回答四件事：讀了哪個 Resource、用了哪個 Tool、結果是哪個時間點取得，以及最後文章的句子是來源事實還是本文推論。MCP 只負責連線與交換格式，這些證據管理仍要由應用層補上。
MCP 和 API、Function Calling、RAG、AI Agent 差在哪裡
MCP 與一般 API
API 通常是某個服務提供的請求介面，規定端點、方法、驗證和資料格式。MCP 可以承載或連接 API，但它在更上層整理了 AI Host、Client、Server 與能力發現的協定互動。
一個 API 可能只有文件中寫好的幾個端點；一個 MCP Server 則可以在連線時宣告多個 Tools、Resources 或 Prompts。這不是說 MCP 比 API 更高級，而是兩者處理的抽象層不同。若你的程式只需要固定呼叫一個內部 API，直接使用 API Client 可能更簡單；若多個 AI Host 需要以一致方式發現和使用一組能力，MCP 才可能減少重複整合。
MCP 與 Function Calling
Function Calling 是模型與應用交換函式名稱、參數與結果的一種能力或模式。應用把函式 schema 提供給模型，模型提出呼叫，應用再執行函式。這通常發生在單一模型 API 與單一應用之間。
MCP 可以讓外部 Server 以標準方式提供 Tools，Host 再把這些工具交給模型使用。因此兩者可以一起出現：MCP 負責外部能力的連接與發現，Function Calling 可能是模型在 Host 內提出工具呼叫的方式。不要因為看到 tools 這個字，就把兩者當成同一個規格。
MCP 與 RAG
RAG 通常指先取得相關資料，再把資料放進模型脈絡以協助回答。MCP Resources 可以成為取得資料的來源，但 MCP 沒有規定你要用向量資料庫、關鍵字搜尋、重排模型或哪種 chunking 策略。
所以「用了 MCP」不等於「已經做好 RAG」。你仍然要驗證資料選取、切分、引用、更新時間和權限；反過來，單純做 RAG 也不必然需要 MCP，如果資料管線與應用已經固定且不需要跨 Host 共用能力。若想先理解模型每一輪真正看到哪些資料，可延伸閱讀 Context Engineering 指南。
MCP 與 AI Agent
AI Agent 是一種由模型根據中間結果動態選擇下一步的工作系統或模式。MCP 可以成為 Agent 取得工具和資料的連線層，但它不負責任務規劃、記憶、停止條件、重試策略或最終驗收。
簡單說，MCP 解決「能力怎麼接上來」；Agent 還要解決「何時用、為什麼用、做到哪裡算完成」。如果你正在處理長任務，可以把 MCP 放在 AI Agent Harness 完整介紹 的工具邊界裡；但不要期待協定本身替你完成整個 Harness。
| 名稱 | 主要問題 | 是否等同 MCP |
|---|---|---|
| API | 應用如何呼叫某個服務 | 否，可被 MCP Server 使用 |
| Function Calling | 模型如何提出函式呼叫 | 否，可在 Host 內搭配 MCP Tools |
| RAG | 如何取得並放入相關資料 | 否，MCP Resources 可是其中一個來源 |
| AI Agent | 如何根據結果規劃與執行多步任務 | 否，MCP 可提供 Agent 的外部能力 |
| MCP | AI Host、Client、Server 如何以共同協定交換能力與脈絡 | 是本文主題，但不包含上述全部責任 |
Local 與 Remote MCP 怎麼選
Local：用 stdio 連接本機程序
本機 MCP Server 可以由 Host 啟動一個程序，透過標準輸入輸出傳送 JSON-RPC 訊息。這種方式適合需要直接讀取本機檔案、在隔離目錄操作或把服務放在開發者自己控制的環境中。
優點是資料可以留在本機邊界內，設定簡單時也不需要先公開一個 HTTP 端點。代價是 Host 啟動的程序可能擁有本機使用者權限；如果設定檔、環境變數或套件來源不可信，風險會直接落在本機環境。因此「本機」不能自動翻譯成「安全」。
Remote：用 Streamable HTTP 連接服務
遠端 MCP Server 目前的官方架構頁以 Streamable HTTP 作為遠端傳輸方式，並說明遠端連線通常需要 OAuth 等授權設計。遠端方式比較適合多個使用者或多個 Host 共用一個服務，也比較容易集中管理服務版本、監控、速率限制與權限。
代價是資料會經過網路，服務端需要處理驗證、授權、租戶隔離、審計、速率限制、timeout、重試與可用性。若某個遠端 Server 的登入方式、資料保留、執行環境或第三方依賴沒有清楚文件，便不應只因為「能連線」就把它接進正式資料。
| 判斷面向 | Local stdio | Remote Streamable HTTP |
|---|---|---|
| 執行位置 | 使用者或 Host 所在環境 | 遠端服務環境 |
| 典型優勢 | 本機資料、開發測試、隔離目錄 | 多 Host 共用、集中管理 |
| 主要風險 | 本機程序權限、套件與密鑰 | 網路傳輸、授權、服務端資料保留 |
| 先驗收什麼 | 啟動命令、檔案範圍、環境變數、子程序權限 | OAuth、租戶隔離、audit、timeout、版本 |
選擇前先回答三個問題
第一，你的資料是否必須留在本機？第二，是否需要讓多個使用者或 Host 共用同一套能力？第三，這個 Server 的每個 Tool 是否都有清楚的權限和副作用說明？
如果只是分析本機草稿，先用只讀、限定目錄的 Local Server 通常比較容易驗收。這是基於風險邊界的本文建議，不是說 Local 一定優於 Remote。若資料本來就在企業服務，而且需要集中權限與審計，Remote 可能比較符合管理需求，但必須先讀回實際授權和資料處理文件。
MCP 安全嗎？先看權限與副作用
協定本身不是安全保證
MCP 可以標準化訊息，但安全性仍取決於 Host、Client、Server、底層 API 和使用者設定。官方 Security Best Practices 特別討論 confused deputy、token passthrough、SSRF、session hijacking 和本機 Server 風險。這些不是靠把名稱改成「AI 安全工具」就會消失的問題。
判斷一個 MCP 連線是否適合使用時，先拆成四層：它能看到哪些資料、它能執行哪些動作、誰能批准這些動作，以及出錯後能否撤回或追查。四層有任何一層沒有答案，就先標成 unknown。
讀取與執行要分開
Resources 主要是資料讀取，Tools 則可能包含查詢以外的寫入或外部副作用。實務上不要只看 Tool 名稱判斷風險，因為一個叫 create、sync 或 update 的 Tool 可能改動正式資料，而一個叫 search 的 Tool 也可能把輸入送到第三方服務。
我會用三種標籤先做最小分類：
- read-only：只讀取已授權資料，沒有外部寫入。
- reversible write：可以建立草稿或可回復的暫存資料。
- irreversible or external action：刪除、發布、付款、寄信、改正式資料或把資料送出系統。
第一類可在驗收後考慮自動化，第二類要有明確輸出位置與回復方式，第三類則應該在 Host 層保留人工確認。這是本文依副作用提出的工作建議，不是把所有產品的預設行為當成已查證事實。
Server 要自己驗證輸入與權限
Client 或模型提供的輸入不能當成可信資料。官方 Tools 規格要求 Server 驗證輸入、執行存取控制、限制速率、清理輸出，並正確處理工具執行錯誤。工具的描述或 annotation 也不能取代 Server 端的真正授權。
如果 Server 需要存取使用者資料，遠端 HTTP 情境通常要檢查 OAuth 流程、token audience、redirect、scope、過期時間和撤銷方式。官方 Authorization 文件也提醒，是否需要授權取決於 Server 要保護的資料與操作；stdio 本機服務則可能使用環境變數或其他本機憑證方式。沒有讀到具體實作，就不要把「支援 OAuth」寫成「已安全完成企業級授權」。
最低限度的安全驗收表
| 驗收項目 | 通過條件 | 未知時怎麼處理 |
|---|---|---|
| Tool 清單 | 每個 Tool 的用途與輸入都能說明 | 不開放高風險 Tool |
| 資料範圍 | 能列出可讀取的目錄、Resource 或帳號 scope | 先用測試資料 |
| 副作用 | 能分辨只讀、可回復、不可回復動作 | 一律要求人工確認 |
| 身分驗證 | 能確認請求者、受眾與授權期限 | 不接正式資料 |
| 結果驗證 | 有 schema、錯誤處理、timeout 和記錄 | 只做小樣本 dry run |
| 撤回與審計 | 知道如何撤銷、回復和查詢歷史 | 停在 preview／draft |
2026-07-28 規格更新，實作時要注意什麼
以查到的版本為界，不把舊教學當成現在規格
MCP 官方 Changelog 顯示 2026-07-28 版本有重要調整，包括移除原本的 session identifier 與相關狀態假設、改以每次請求的 metadata 支援，以及調整 Server discovery、通知、Tasks 和其他能力的位置。這表示網路上仍然看得到的舊文章，不一定能直接套用在現在的 Client 或 Server。
本文不是版本遷移指南，也沒有在你的環境中測試任何特定 SDK。實作時應該把協定版本、SDK 版本、Server 版本和 Host 支援分開記錄。不要只在設定檔裡留一個「MCP enabled」就當成完成。
Core primitives 與 Extensions 不要混為一談
目前官方架構說明把 Tools、Resources、Prompts 列為核心原語，同時指出 sampling、logging 等部分能力的狀態有變化，Tasks 也移到 extension 的脈絡。某個產品說「支援 MCP」，仍然不代表它支援所有核心原語、授權流程、通知或 extension。
做相容性判斷時，至少要拆出：
- Host 支援的 MCP 版本與傳輸方式。
- Client 能否發現與呼叫 Tools。
- 是否能讀 Resources、套用 Prompts。
- 是否支援 OAuth、通知、訂閱或特定 extension。
- Server 實際宣告與實作的能力。
用 readback 取代設定畫面的想像
如果你要把 MCP 接到工作流程，建議留下這張版本表：
| 欄位 | 實際讀回值 | 證據位置 |
|---|---|---|
| Host | 名稱、版本、帳號或工作區 | Host 設定或官方文件 |
| Client | 版本、傳輸、已協商協定版本 | 初始化 log |
| Server | 名稱、版本、啟動位置或 endpoint | Server manifest／啟動輸出 |
| Capabilities | Tools、Resources、Prompts 與其他能力 | capabilities response |
| Authorization | scope、token audience、授權日期 | 授權設定與服務端文件 |
| Tool result | 輸出 schema、錯誤型態、執行時間 | dry run log |
如果某一欄沒有可讀回的證據，填 unknown；如果 Server 沒有任何結果資料，填 no_data。不要為了讓表格看起來完整而把它們補成「支援」或「正常」。
低風險導入 MCP 的驗收流程
以下流程是本文根據官方能力與安全邊界整理的實作建議，適合第一次評估 MCP。它不是任何供應商的正式導入規範。
第一步：先寫清楚要解決的重複整合
列出目前真正的痛點：是多個 AI Host 都要查同一個資料庫？是每個應用都重寫同一組工具 schema？還是只想把一個本機腳本接到聊天介面？
如果問題只是「我想讓模型讀一個固定檔案」，先用清楚的檔案上傳或本機腳本也許足夠。MCP 的價值通常在於能力需要被多個 Host 以一致方式發現與使用，而不是名詞本身比較新；若要把工具接進固定流程，也可以先看 如何把工作自動化。
第二步：畫出資料與副作用邊界
先把可讀資料、可執行動作、不可碰的資料和需要人工核准的動作列出來。把正式帳號、個人密鑰、客戶資料和公開測試資料分開，不要第一次就用正式環境驗證。
第三步：只開一個低風險 Server
優先選擇能在限定目錄內讀取測試資料的 Server，並把寫入、刪除、發布等 Tool 暫時關閉或移除。若使用第三方 Server，先讀來源、維護者、依賴套件、更新時間和資料處理說明；沒有資料的項目記為 unknown。
第四步：完成 discovery、dry run 和錯誤測試
先讀回初始化版本與 capabilities，再列出實際 Tools、Resources、Prompts。每個 Tool 至少測試一次正常輸入、一次缺少欄位、一次型別錯誤和一次超出權限的輸入。確認錯誤會被清楚回傳，也確認錯誤不會默默改動外部資料。
第五步：讓人能在副作用前停止
把需要人工確認的事件顯示在 Host 的可見位置，包含 Tool 名稱、輸入摘要、目標資料、可能副作用和核准後的下一步。通過測試後，再逐步擴大資料或 Tool 範圍；每一次擴大都重新讀回能力清單與權限。
| 步驟 | 最小產物 | 未通過時 |
|---|---|---|
| 定義問題 | 一句可驗收的整合目標 | 先不用 MCP |
| 邊界盤點 | 資料、Tool、副作用與核准表 | 縮小範圍 |
| 版本發現 | Host、Client、Server 與 capabilities | 停止安裝或升級 |
| 小樣本測試 | 正常、錯誤、越權 dry run | 不接正式資料 |
| 人工 Gate | 副作用前的可見核准點 | 維持只讀模式 |
| 結果回查 | log、來源、輸出與撤回證據 | 停在 draft 或 preview |
哪些情境適合 MCP，哪些不用急著用
適合評估 MCP 的情境
如果同一組外部能力要被多個 AI Host 使用，而且每個 Host 都需要知道工具清單、輸入格式和資料來源，MCP 有機會讓整合邊界更一致。另一個適合情境是你希望把資料讀取和工具執行從 Host 主程式拆出來，讓 Server 可以獨立維護。
例如一個團隊可能希望開發環境、研究工作台與內部聊天工具都能以相近方式查詢文件庫。這只是架構上的合理情境，不代表所有三種產品都已支援同一套 MCP 功能；實際可行性要看它們的 Client 能力與權限設計。
不適合為了流行名詞硬接的情境
如果只有一個固定 API、一次性腳本或一份不會變的本機檔案，直接使用現有 API Client、檔案流程或固定 Workflow 往往比較容易測試。這是基於最小複雜度的建議，不是宣稱 MCP 在這些情境永遠沒有價值。
如果團隊還沒有基本的權限、測試、log 和資料分類制度，也不建議第一步就開放能改動正式系統的 MCP Tools。協定越容易連上，越需要先把連上後的責任寫清楚。
用三個決策問題收斂
- 是否有兩個以上的應用需要共用同一組外部能力？
- 這組能力是否值得用一份可發現、可版本化的協定契約來管理？
- 是否已經能清楚控制資料範圍、Tool 副作用、授權與驗收？
若第一題答案是否定的，先維持簡單流程；若第二或第三題答案是否定的，先補文件、測試和權限邊界。只有三題都能回答，才值得進入 MCP 的小樣本導入。
常見誤解與排查順序
「MCP 裝好了，模型就能看到所有資料」
模型只能看到 Host 實際提供給它的資訊，Host 也只能透過 Client 取得 Server 暴露且授權允許的內容。即使某個 Server 底層能連到整個資料庫，這也不代表每個 Tool 或每個使用者都能讀取全部資料。
排查時先看實際 Resource、Tool scope、帳號、資料庫權限與 Host 傳入的內容，而不是只看 Server 的安裝說明。
「MCP 就是 AI Agent」
MCP 不包含任務規劃、長期記憶、自主迴圈和驗收規則。若 Agent 亂呼叫工具，先看模型提示、工具描述、停止條件和人工 Gate；不要只重裝 MCP Server。
「能列出 Tool 就代表 Tool 可靠」
列出工具只是 discovery 成功。你還要測試輸入 schema、權限、timeout、錯誤處理、輸出內容與副作用。工具名稱和描述是幫助模型理解的資訊，不是安全認證。
「Remote 一定危險，Local 一定安全」
Remote 多了網路與服務端授權要檢查，Local 則可能讓本機程序取得使用者檔案、環境變數或其他權限。真正的風險取決於資料流、權限、依賴、隔離和可追查性，位置只是其中一個因素。
遇到連不上時的排查順序
按照這個順序通常比較省時間：
- 確認 Host、Client、Server 的實際版本與啟動狀態。
- 確認傳輸方式和 endpoint 或 stdio 啟動參數。
- 讀回初始化協定版本與 capabilities。
- 查看 tools/list、resources/list 或 prompts/list 是否真的有結果。
- 用低風險輸入測試 schema、授權、timeout 與錯誤。
- 最後才檢查模型是否選錯 Tool 或需要調整提示。
這個順序把連線問題、能力問題、權限問題和模型判斷分開，不會把所有錯誤都歸因於「模型不夠聰明」。
FAQ：MCP 常見問題
MCP 是什麼的縮寫？
MCP 是 Model Context Protocol 的縮寫。它是連接 AI 應用與外部系統的開放協定，用來整理 Host、Client、Server 以及 Tools、Resources、Prompts 之間的溝通方式。
MCP 是一個模型嗎？
不是。MCP 不負責產生文字或做模型推理；模型通常由 Host 所承載的 AI 應用使用。MCP 主要處理應用如何發現與交換外部能力和資料。
MCP Server 一定要部署在雲端嗎？
不一定。官方架構同時描述本機 stdio 與遠端 Streamable HTTP 傳輸。Server 可以是本機程序，也可以是遠端服務；選擇要依資料位置、共用需求、授權、隔離和維運能力判斷。
MCP 和 API 有什麼差別？
API 是服務提供的請求介面；MCP 是讓 AI Host、Client 與 Server 以共同方式交換能力與脈絡的協定。MCP Server 可以包住或呼叫 API，但兩者不是同一層，也不是互相取代的關係。
MCP 和 RAG 是一樣的嗎？
不是。RAG 是取得相關資料並放入模型脈絡的工作模式；MCP Resources 可以提供資料來源，但 MCP 不規定搜尋、切分、重排或引用策略。是否真的做到可靠 RAG，仍要看資料管線與驗收。
接上 MCP 後，AI 會自動執行所有工具嗎？
不應該這樣假設。模型可能提出工具呼叫，但 Host、Client 和 Server 仍應檢查權限、輸入與副作用；高風險操作最好保留使用者核准。實際是否有確認畫面則要看使用中的 Host。
我應該先安裝幾個 MCP Server？
本文建議先從一個限定資料範圍、只讀或低副作用的 Server 開始。先完成版本、能力、權限、錯誤和結果驗收，再決定是否增加其他 Server。安裝數量本身不是導入成功的指標。
為什麼網路上的 MCP 教學和我的設定不一樣？
MCP 規格、SDK、Host 與 Server 都會更新。官方 2026-07-28 規格已經調整部分 session、discovery、通知與 extension 的設計；請先確認教學的日期、規格版本、SDK 版本和產品文件，再比較設定。
結語：把連線能力和授權責任分開
MCP 最值得理解的地方，不是它又多了一個 AI 名詞，而是它把「AI 應用如何連到外部工具與資料」這段責任抽出來。Host 承載工作與使用者互動，Client 管理與單一 Server 的連線，Server 則提供 Tools、Resources、Prompts。知道三個角色之後，很多「為什麼看得到工具卻不能用」或「為什麼接上了卻不安全」的問題會比較容易拆開。
本文的導入建議很簡單：先確認是否真的有跨應用共用能力的需求，再從限定範圍的只讀 Server 開始，讀回版本與 capabilities，測試正常與錯誤輸入，並把副作用前的人工核准和結果回查保留下來。MCP 可以讓連線更一致，但可靠性仍然要靠權限、資料品質、版本管理與驗收補上。
如果你現在只是想讓 AI 讀一份固定資料，不必為了名詞而增加架構。若你確實要讓多個 Host 共用一組可發現的外部能力，MCP 才值得成為下一步評估對象；至於某個具體產品、Server 或帳號是否支援，請以當下可讀回的官方文件和實際能力清單為準。
參考來源
- MCP 官方 What is MCP?
- MCP Architecture，2026-07-28
- MCP Server concepts，2026-07-28
- MCP Tools specification，2026-07-28
- MCP Resources specification，2026-07-28
- MCP Prompts specification，2026-07-28
- MCP Security Best Practices
- MCP Authorization，2025-06-18
- MCP Changelog，2026-07-28
- Anthropic：Introducing the Model Context Protocol
以上來源與本文範圍最後查閱日期：2026-09-12（Asia/Taipei）。產品方案、帳號權限、特定 Host／Client／Server 的實際支援、資料保留與服務可用性，除非有當次讀回證據，均保留為 unknown。