MCP 是什麼？新手也能看懂的 Model Context Protocol 入門指南

Anthropic 後來把 MCP 捐給 Linux Foundation 旗下的 Agentic AI Foundation，讓協議朝開放、中立與社群治理發展。到了 2026-07-28 正式規格，MCP 核心改為每次請求自帶必要資訊的 stateless 架構，進一步處理遠端部署、擴充與企業授權需求。

為什麼 AI 需要 MCP？

大型語言模型可以理解文字、產生內容與進行推理，但它天生不會自動知道你的最新資料，也不能憑空取得私人文件或操作公司系統。

要讓 AI 真正協助工作，通常必須解決三件事：

拿到正確上下文：例如專案文件、客戶資料、行事曆、商品庫存或最新報表。
知道有哪些動作可做：例如搜尋、建立任務、寄信、更新 CRM 或執行測試。
在安全範圍內執行：包含登入授權、最小權限、操作確認、日誌與錯誤處理。

沒有共同標準時，每個 AI 應用或 AI Agent 都要各自整合每個外部服務。N 個 AI 應用要連 M 個工具，最壞會形成 N × M 組客製串接。開發者除了寫連線程式，還要重複處理工具描述、參數格式、權限、回傳內容與錯誤。

MCP 的目標，是把「AI 如何看見與使用外部能力」這一層標準化。外部系統只要提供合適的 MCP Server，相容的 AI Host 就能用共同規則連接它，減少每一組產品都重新發明整合方法的成本。

MCP 的基本架構

新手先記住三個角色：Host、Client、Server。

1. Host：你正在使用的 AI 應用

Host 是承載模型、對話、權限與使用者介面的主要應用，例如 AI 助理、程式編輯器或企業內部 Agent。你通常是在 Host 裡提出需求，例如：「找出下週所有人都有空的一小時。」

2. Client：Host 裡負責 MCP 溝通的連接元件

Client 負責和某一個 MCP Server 交換協議訊息。它取得 Server 提供的能力、送出工具呼叫、接收結果，並把資料交回 Host。一般使用者不一定會直接看見 Client。

3. Server：把資料與工具能力提供出來

MCP Server 可以直接讀取允許的檔案或資料庫，也可以在背後呼叫既有 API。它把能力用 MCP 規格描述出來，例如「列出行事曆事件」「搜尋文件」「建立 issue」「查詢訂單」。

一個常見流程如下：

使用者在 Host 提出自然語言需求。
Host 讓模型看見可用工具，模型再判斷要用哪個工具與參數。
MCP Client 把呼叫送到 MCP Server。
Server 查 API、資料庫、檔案或其他系統。
結果經 Client 回到 Host，模型再整理、比較或規劃下一步。

MCP 呼叫 API 的五步流程：使用者提出目標、模型選工具、Client 呼叫 Server、Server 存取 API、結果回傳給 AI

這個流程的重點是：模型不直接拿著你的 API key 隨便呼叫服務。實際權限、連線、確認與執行責任，仍應由 Host、Client、Server 與底層服務共同控管。

MCP 的三個重要功能：Tools、Resources、Prompts

MCP Server 可以提供不同能力，新手最先需要理解的是 Tools、Resources、Prompts。

Tools：讓模型提出要執行的動作

Tool 是可呼叫的函式或操作，例如查資料庫、搜尋文件、建立 GitHub issue、列出行程、更新 CRM 或執行測試。工具最有行動力，也最需要權限、輸入驗證與高風險操作確認。

Resources：提供可讀取的資料與上下文

Resource 可以是文件、專案檔案、資料庫 schema、Git history、圖片或其他結構化內容。它的重點是讓 Host 或模型取得處理任務需要的資料，不等同於自動執行動作。

Prompts：可重複使用的任務模板

Prompt 是預先設計好的訊息與工作流程模板，例如程式碼審查、客服回覆、週報整理或資料分析模板。它可以讓常見任務的輸入方式與輸出格式更一致。

依照官方規格的控制概念，Prompts 偏向由使用者選用，Resources 偏向由應用管理，Tools 則可能由模型依任務判斷是否呼叫。無論是哪一種，Host 都應保留權限與使用者控制。

MCP 跟 API 有什麼不同？

最短答案是：API 讓軟體呼叫某項服務；MCP 則讓 AI 用共同格式看懂「有哪些工具、怎麼使用」。兩者通常一起工作，不是互相取代。

先用餐廳來比喻

API 像餐廳原本的點餐窗口；MCP 像提供給 AI 服務生的通用菜單與點餐單。

每家餐廳的 API 都可能有自己的菜名、欄位與點餐規則，工程師要逐家閱讀文件並寫串接程式。MCP Server 則用共同格式告訴 AI：有哪些「菜」可以選、每道菜需要哪些資料，以及送單後會得到什麼結果。

AI 因此比較容易在不同工具之間做選擇；但真正接單、計價與出餐的，通常仍是餐廳原本的 API 或後端系統。也就是說，MCP 是讓 AI 看懂並使用 API 的翻譯層，不是把 API 拿掉。

換成行事曆任務來看

直接使用 API：工程師先寫好何時查行事曆、要帶哪些參數，以及查完後如何找空檔，流程固定而可控。

使用 MCP：使用者只要說「找出下週大家都有空的一小時」，AI 就能從 MCP Server 提供的工具中選擇「列出事件」或「查詢空檔」，再由 Server 呼叫底層行事曆 API。

MCP 與 API 比較表

比較項目	API	MCP
主要用途	讓程式呼叫服務	讓 AI 發現並使用工具
整合方式	工程師閱讀各家文件並寫程式	Server 用共同格式描述工具與參數
呼叫時機	通常由固定程式流程決定	AI 可依自然語言目標選擇工具
適合情境	固定、高流量、低延遲的流程	多步任務、Agent、跨工具協作
兩者關係	實際提供資料或執行動作	背後經常仍會呼叫 API
安全重點	金鑰、OAuth、權限與輸入驗證	除 API 安全外，還要管理工具信任與使用者確認

API 與 MCP 的分工：固定流程直接用 API，AI 彈性任務用 MCP，實務上常由 MCP Server 呼叫 API

不過，MCP 不會讓底層 API 免費，也不會省略 OAuth、權限、速率限制與安全檢查；因為多了一層 AI 判斷與工具往返，延遲也可能增加。

MCP、API、Function Calling、RAG 放在什麼位置？

這四個名詞常被放在一起，因為它們都可能出現在 AI 工具整合流程中，但負責的事情不同。

API：外部系統真正提供資料或動作的介面，例如查訂單、列行程、發訊息。
Function Calling／Tool Calling：模型輸出「我想呼叫某個函式與這組參數」的機制。應用程式收到後，仍要自己執行函式。
MCP：讓 Host、Client、Server 用共同方式描述與交換 Tools、Resources、Prompts。Host 內部可能再把 MCP Tool 轉成模型能使用的 Function Calling schema。
RAG：先從文件庫或搜尋系統檢索相關內容，再把內容放進模型上下文的做法。MCP Server 可以把 RAG 搜尋包成 Tool 或 Resource。

一個完整企業助理可能同時使用四者：模型透過 Function Calling 選擇 MCP Tool，MCP Server 呼叫公司 API 或 RAG 系統，最後把查到的內容交回模型整理。

什麼時候用 API、MCP，或兩者一起用？

優先直接使用 API

流程固定，輸入與輸出都很明確。
需要大量請求、低延遲或嚴格成本控制。
重要商業規則必須可測試、可重現，不希望交給模型判斷。
只有一個產品需要整合，沒有跨 AI Host 重用需求。

優先考慮 MCP

希望同一組工具能被多個相容 AI 應用使用。
使用者會用自然語言提出多變、難以預先列完的任務。
Agent 需要在多個資料源與工具之間規劃步驟。
要把內部工具以一致格式提供給 AI，而不是每個 Client 各寫一次。

最常見的是 MCP 加 API

多數成熟做法不是二選一，而是保留既有 API 作為穩定後端，再建立 MCP Server 作為 AI 轉接層。固定程式繼續直接用 API；AI 助理則透過 MCP 使用相同能力。

想看單一服務的實際例子，可以延伸閱讀Ahrefs 手查、API、MCP 與報表的差異；若要直接設定 SEO 工具，另可參考Ahrefs MCP 用途與設定教學。

如果任務涉及付款、刪除、部署、寄信或修改正式資料，無論走 API 或 MCP，都應把最終商業規則放在可靠的後端，並加入權限檢查、冪等控制、審批或人工確認。

ChatGPT、Gemini、Claude 怎麼串 MCP？

不同產品的按鈕、方案與支援範圍會更新，但核心結構相同：先準備 MCP Server，再讓支援 MCP 的 Host／Client 連接它，取得可用工具與資料能力。

ChatGPT 與 OpenAI API

ChatGPT 的使用者通常看到 App 或 Connector；開發者則可以依 OpenAI 的 MCP 與 Connectors 文件，把 remote MCP server 當成工具接進 API 應用。遠端 Server 會接觸傳送給它的資料，因此要另外檢查第三方資料保存與權限政策。

Gemini 與開發者工具

Gemini 的 MCP 使用常見於 Gemini CLI 與 coding agent 場景。開發者可以在設定中加入一個或多個 MCP Server，讓 Agent 在寫程式、查文件或執行開發任務時使用。實際設定請以 Gemini CLI 官方文件為準。

Claude Desktop 與 Claude Code

Claude 生態很早就支援 MCP。Claude Code 可以加入本機或遠端 MCP Server，Claude Desktop 常被用來連接本機檔案與工具；團隊導入時則應管理共同設定與允許的 Server。實際指令、scope 與 transport 以 Claude Code 官方 MCP 文件為準。

以上產品支援情況查核日期為 2026-08-28；介面、方案與功能名稱可能調整。

實作教學：在 Claude 新增自訂連接器

一般使用者在 Claude 設定裡可能會看到 Connectors 與「Add custom connector」。你需要填入服務提供的名稱與 Remote MCP server URL；若服務使用特殊 OAuth 設定，才可能需要額外的 Client ID 或 Client Secret。

Name：自己辨認用的顯示名稱，例如「公司知識庫」。
Remote MCP server URL：服務提供的遠端 MCP endpoint，不是一般網站首頁或任意 API URL。
OAuth Client ID／Secret：只有服務明確要求時才填；Secret 不應貼到一般對話或公開文件。

新增前先確認 Server 的提供者、網域、權限與資料政策。連接成功也不代表每一個工具都應自動執行；高風險動作仍要保留確認。

Claude 新增自訂 MCP 連接器的設定畫面，包含名稱、遠端 MCP Server URL 與 OAuth 欄位

這是既有操作截圖；介面可能隨產品更新而改變，請以帳號中的最新畫面為準。

MCP 的好處

降低重複整合：把外部能力整理成相容 Server，減少每個 AI 應用各寫一套工具描述與連接方式。
提高可組合性：Agent 可以在文件、資料庫、任務系統與其他工具之間完成多步工作。
讓上下文更貼近現況：模型能在授權範圍內取得最新或私有資料，不只靠訓練記憶。
建立治理邊界：Host 與 Server 可以集中處理權限、允許工具、確認與日誌。

但這些好處只有在 Server 描述清楚、權限合理、錯誤可追蹤時才成立。把不穩定 API 隨便包成 MCP，不會自動變成可靠產品。

MCP 可以拿來做什麼？

個人助理：連接行事曆、筆記、待辦與雲端文件。
AI Coding：讀取專案檔案、Git history、issue、log 與測試結果。
企業知識庫：搜尋 Google Drive、Notion、Confluence、SharePoint 或內部文件。
資料分析：查詢資料庫、資料倉儲與 BI 指標。
客服與 CRM：讀取訂單、客戶紀錄、過去對話與產品文件。
行銷與內容：查品牌規範、SEO 資料、文章庫與成效報表。
設計與產品：連接設計稿、規格、任務系統與程式碼。
DevOps：讀取監控、log 與 incident 資料，必要時在確認後執行操作。

這些場景的共同點是：AI 先取得必要上下文，再於授權範圍內查詢或執行。只要涉及正式資料變更，就應加入更嚴格的驗證與確認。

新手與工程師怎麼開始使用 MCP？

一般使用者

不用先學會寫 Server。從可信任的 App 或 Connector 開始，連接前確認三件事：

它會讀取哪些資料？
它能執行哪些會改變資料的動作？
權限能否縮小、撤銷，重要動作是否會再次確認？

工程師

先從唯讀、低風險工具開始，例如列出檔案、查詢公開資料或搜尋測試文件。用官方 SDK 與 MCP Inspector 檢查 Tools、Resources、Prompts 的 schema 與回傳，再逐步加入 OAuth、scope、日誌、逾時、重試上限與寫入確認。

若公司已經有穩定 API，不必重寫後端。先做一個薄的 MCP Server，把既有 API 包成清楚、可驗證、權限受控的 Tool，通常是更實際的導入路線。

MCP 很強，但不要忽略安全風險

MCP 讓 AI 接觸外部資料與工具，也會建立新的信任邊界。官方規格要求重視使用者同意、資料隱私與 Tool 安全，並提醒 Tool 可能代表任意程式執行能力。

實務上至少要做到：

只安裝可信任來源的 MCP Server，核對網域、程式碼與更新機制。
採最小權限，只開放任務需要的資料、資料夾與動作。
把 Tool 描述與外部內容視為不完全可信，防範提示注入與工具投毒。
寄信、付款、刪除、部署、修改正式資料前保留人工確認。
留下誰在何時讀取什麼、呼叫什麼工具、結果如何的稽核紀錄。
不要把 API key、Client Secret 或私人 token 貼進一般對話。

可再參考 OWASP MCP Top 10與 MCP Security Cheat Sheet。企業導入時，IT、安全、法務與資料治理應共同參與。

MCP 適合誰？

一般使用者：不一定要懂協議細節，但要看懂授權範圍、資料流向與動作確認。
工程師：適合用 MCP 把 API、資料庫與內部工具提供給 AI Coding 或 Agent。
產品經理與創業者：可以評估產品能力是否值得提供成可信任的 MCP Server。
企業 IT：可用 MCP 標準化 AI 與內部工具的連接，但必須同步建立 allowlist、權限與稽核。

MCP 不適合什麼情境？

只問一般知識、翻譯或摘要一小段已提供的文字。
單一、固定、低延遲的後端流程，直接 API 更簡單可控。
組織沒有基本權限、日誌、資料分級與 API 管理，卻想直接開放高權限工具。
不允許模型參與工具選擇，所有步驟都必須完全確定與可重現的關鍵交易。

MCP 是整合工具，不是讓所有系統自動變成 Agent 的魔法。若只是增加一層協議，卻沒有明確的跨 AI 重用或彈性任務需求，反而會增加維運成本。

總結

MCP 是一套讓 AI 應用標準化連接外部資料、工具與工作流程的開放協議。

API 與 MCP 最大的差異，不是誰比較新，而是解決的層級不同：API 讓軟體提供能力；MCP 讓 AI 應用用共同方式理解、選擇與呼叫能力。

真正的系統通常會把兩者疊在一起：底層 API 保持穩定、快速與可測試；上層 MCP Server 把能力整理成 AI 可使用的 Tools 或 Resources；Host 再負責模型、權限與使用者確認。

一句話記住：API 是能力入口，MCP 是 AI 使用這些能力的共同語言。

MCP 常見問題

MCP 是 AI 模型嗎？

不是。MCP 是協議，不是 ChatGPT、Claude、Gemini 或其他大型語言模型。

MCP 是外掛嗎？

不完全是。某個 MCP Server 可以帶來類似外掛的能力，但 MCP 本身是讓 AI 應用、資料源與工具溝通的一套規則。

MCP 會取代 API 嗎？

不會。許多 MCP Server 背後仍要呼叫 API。API 也會繼續用於固定產品流程、服務間整合與大量請求。

有 API 就一定要再做 MCP 嗎？

不一定。只有當你想讓能力被 AI Agent 用自然語言選擇、跨多個相容 Host 重用，或要標準化 AI 工具描述時，MCP 才特別有價值。

MCP 比直接呼叫 API 省錢嗎？

不一定。底層 API 的費用與配額仍在，MCP 還可能增加模型 token、工具往返與 Server 維運成本。是否省錢要看重用程度、請求量與流程設計。

MCP 和 Function Calling 一樣嗎？

不一樣。Function Calling 是模型產生函式呼叫意圖與參數的機制；MCP 是 Host、Client、Server 交換工具、資源與提示的開放協議。Host 可以把 MCP Tool 提供給模型作 Function Calling。

MCP 會取代 RAG 嗎？

不會。RAG 是檢索資料並放進模型上下文的做法；MCP 可以把 RAG 查詢包成 Tool 或 Resource，兩者經常一起用。

MCP 安全嗎？

MCP 不是自動安全或自動危險。風險取決於 Server 可信度、權限設計、資料範圍、Host 的確認流程與稽核。高風險動作應採最小權限並保留人工確認。

延伸閱讀

本文技術與產品資訊查核日期：2026-08-28。MCP 規格、AI 產品介面、授權流程與支援功能可能更新，實作前請以官方文件為準。

MCP 是什麼？

MCP 是誰推出的？為什麼突然變熱門？

為什麼 AI 需要 MCP？

MCP 的基本架構

1. Host：你正在使用的 AI 應用

2. Client：Host 裡負責 MCP 溝通的連接元件

3. Server：把資料與工具能力提供出來

MCP 的三個重要功能：Tools、Resources、Prompts

Tools：讓模型提出要執行的動作

Resources：提供可讀取的資料與上下文

Prompts：可重複使用的任務模板

MCP 跟 API 有什麼不同？

先用餐廳來比喻

換成行事曆任務來看

MCP 與 API 比較表

MCP、API、Function Calling、RAG 放在什麼位置？

什麼時候用 API、MCP，或兩者一起用？

優先直接使用 API

優先考慮 MCP

最常見的是 MCP 加 API

ChatGPT、Gemini、Claude 怎麼串 MCP？

ChatGPT 與 OpenAI API

Gemini 與開發者工具

Claude Desktop 與 Claude Code

實作教學：在 Claude 新增自訂連接器

MCP 的好處

MCP 可以拿來做什麼？

新手與工程師怎麼開始使用 MCP？

一般使用者

工程師

MCP 很強，但不要忽略安全風險

MCP 適合誰？

MCP 不適合什麼情境？

總結

MCP 常見問題

MCP 是 AI 模型嗎？

MCP 是外掛嗎？

MCP 會取代 API 嗎？

有 API 就一定要再做 MCP 嗎？

MCP 比直接呼叫 API 省錢嗎？

MCP 和 Function Calling 一樣嗎？

MCP 會取代 RAG 嗎？

MCP 安全嗎？

延伸閱讀

Frank Chiu

訂閱電子報

相關文章

AI Agent 用 Windows 還是 Mac？Codex、Claude 差異

Claude Code Mod 是什麼？用途與入門

Codex 雲端怎麼用？環境設定與任務驗收教學