MCP 是什麼？新手也能看懂的 Model Context Protocol 入門指南
MCP 是什麼、MCP 解決什麼問題、MCP 跟 API / RAG / Function Calling 差在哪裡、MCP 的好處、應用情境、入門方式，以及使用 MCP 時一定要注意的安全風險。
MCP 是 Model Context Protocol 的縮寫，中文可以理解成「模型上下文協議」。
MCP 是一套讓 AI 應用程式連接外部資料、工具、軟體與工作流程的開放標準。
如果你最近常看到 ChatGPT、Claude、Cursor、VS Code、AI Agent、自動化工具都在討論 MCP，原因很簡單：AI 已經不只是聊天機器人，開始變成可以讀資料、用工具、執行任務的工作夥伴。
而 MCP 的角色，就是幫這些 AI 工具建立一套共同的連接方式。
過去我們使用 AI，大多是在對話框裡問問題，然後等 AI 回答。
但真正的工作常常不只是問答，而是需要 AI 幫我們讀 Google Drive、查資料庫、看 GitHub issue、分析報表、建立任務、整理 CRM、查詢內部文件，甚至串接公司系統。
這時候，如果每個 AI 工具都要各自串接每個外部服務，開發成本會非常高。
MCP 就是為了解決這個問題而出現。
本文會用新手也能理解的方式，介紹：MCP 是什麼、MCP 解決什麼問題、MCP 跟 API / RAG / Function Calling 差在哪裡、MCP 的好處、應用情境、入門方式，以及使用 MCP 時一定要注意的安全風險。
MCP 是什麼？
MCP，全名是 Model Context Protocol，是一套讓 AI 應用程式用標準方式連接外部系統的開放協議。
你可以先把 MCP 想成「AI 工具的通用連接埠」。
MCP 官方文件也用 USB-C 來比喻 MCP：USB-C 讓不同設備能用同一種接口連接螢幕、硬碟、充電器；MCP 則讓不同 AI 應用能用同一套標準，連接資料庫、檔案、工具、API、企業系統與工作流程。
例如 AI 原本只能回答：「我不知道你的行事曆內容。」
但如果 AI 透過 MCP 連接 Google Calendar，它就能在你授權的情況下讀取會議行程，幫你整理今天有哪些會議、要準備哪些資料，甚至搭配其他工具產出待辦事項。
再例如 AI 原本不知道你公司內部文件裡寫什麼。
但如果公司建立一個 MCP Server，讓 AI 可以在權限範圍內查詢 Notion、Google Drive、Confluence 或內部知識庫，它就能回答更貼近公司現況的問題。
MCP 的重點不是讓模型變聰明而已，而是讓 AI 可以「連接真實世界」。
MCP 是誰推出的？為什麼突然變熱門？
MCP 最早由 Anthropic 在 2024 年 11 月公開推出，Anthropic 也就是 Claude 背後的 AI 公司。
Anthropic 在推出 MCP 時，把它描述為一個連接 AI 助理與資料所在系統的新標準，包含內容資料庫、商業工具與開發環境。
一開始 MCP 主要被用在 Claude Desktop、Claude Code、開發者工具與資料連接場景，但很快被更多 AI 生態採用。
到了 2025 年後，MCP 開始快速成為 AI Agent 與 AI 應用串接工具的重要標準。
Anthropic 於 2025 年 12 月宣布，將 MCP 捐給 Linux Foundation 旗下的 Agentic AI Foundation（AAIF），讓 MCP 進一步朝開放、中立、社群治理的方向發展。
這代表 MCP 不只是某一家公司的內部功能，而是正在成為 AI Agent 時代的重要基礎建設。
為什麼 AI 需要 MCP？
大型語言模型很強，但它天生有幾個限制。
第一，它不一定知道最新資訊。
第二，它不知道你的私人資料、公司資料、工作文件與內部系統。
第三，它不能自己憑空操作真實世界的軟體，例如寄信、查資料庫、建立任務、更新 CRM 或執行程式。
Google Cloud 對 MCP 的中文介紹也提到，LLM 的限制在於知識停留在訓練時間點，且缺乏與外界互動的能力；MCP 則是讓模型能與外部資料、應用程式和服務溝通的標準化方式。
以前要解決這個問題，開發者通常要替每個 AI 應用，客製化串接每個工具。
例如要讓 AI 連 Google Drive，要寫一套；要連 Slack，又寫一套；要連 Postgres，又寫一套；要讓另一個 AI 產品也支援同樣功能，可能還要再寫一次。
這就會變成很麻煩的「N x M 問題」。
N 個 AI 應用，M 個外部工具，理論上會產生 N 乘 M 種整合需求。
MCP 想解決的就是這件事。
有了 MCP，開發者可以把某個外部工具或資料源包裝成 MCP Server，支援 MCP 的 AI 應用就可以用標準方式連上去。
這會大幅降低整合成本，也讓 AI 工具更容易互通。
MCP 的基本架構
MCP 的架構不算複雜，新手先記住三個角色就好：Host、Client、Server。
MCP 2025-11-25 規格說明，MCP 使用 JSON-RPC 2.0 訊息，讓 Host、Client、Server 之間建立溝通。
1. Host：你正在使用的 AI 應用
Host 可以理解成 AI 的主要使用介面。
例如 Claude Desktop、ChatGPT、Cursor、VS Code、企業內部 AI 助理，都可以是 MCP Host。
使用者通常是在 Host 裡輸入需求，像是：「幫我查這個專案最近有哪些 GitHub issue 還沒處理。」
2. Client：Host 裡負責連線的中介層
Client 是 Host 裡面負責跟 MCP Server 溝通的元件。
一般使用者不一定會直接看到 Client，但它負責處理連線、傳遞請求、取得工具清單、接收回傳結果。
3. Server：提供資料或工具能力的服務
Server 是 MCP 最重要的角色之一。
它可以提供資料，也可以提供工具。
例如：
- Google Drive MCP Server：讓 AI 讀取雲端文件。
- GitHub MCP Server：讓 AI 查 issue、pull request、repository 資訊。
- Postgres MCP Server：讓 AI 查詢資料庫。
- Slack MCP Server：讓 AI 搜尋訊息或協助發送訊息。
- Figma MCP Server：讓 AI 讀取設計稿，協助工程師轉成程式碼。
整體流程大概會像這樣：
- 你在 AI 應用中提出需求。
- AI 判斷自己需要外部資料或工具。
- MCP Client 去詢問 MCP Server 有哪些工具可以用。
- AI 在你授權後呼叫對應工具。
- MCP Server 執行查詢或動作，並把結果回傳給 AI。
- AI 根據結果整理成你看得懂的答案。
這就是 MCP 最核心的運作方式。
MCP 的三個重要功能：Tools、Resources、Prompts
MCP Server 可以提供很多能力，但新手最先需要理解的是三個：Tools、Resources、Prompts。
在 MCP 官方規格中，Server 可以提供 Resources、Prompts、Tools；其中 Resources 是資料與上下文，Prompts 是任務模板，Tools 則是模型可以執行的函式或工具。
Tools：讓 AI 可以執行動作
Tools 是 MCP 裡最容易理解的功能。
它代表 AI 可以呼叫某個工具來做事。
例如：
- 查詢資料庫。
- 搜尋公司內部文件。
- 建立 GitHub issue。
- 查詢天氣或匯率。
- 執行測試指令。
- 更新 CRM 客戶資料。
Tools 的重點是「動作」。
如果你讓 AI 透過 MCP 呼叫一個寄信工具，理論上它就可能幫你寄出信件。
因此 Tools 很強，但也最需要權限控管。
Resources：讓 AI 可以讀取資料
Resources 是提供上下文資料給 AI 使用。
例如：
- 文件內容。
- 資料庫 schema。
- 專案檔案。
- 內部知識庫文章。
- 使用者設定。
- Git commit history。
Resources 的重點是「提供資料」。
這可以讓 AI 不只依靠訓練資料回答，而是能根據你指定的最新資料、私有資料或企業資料回答。
Prompts：讓 AI 使用預先設計好的任務模板
Prompts 是可以重複使用的任務模板。
例如：
- 程式碼審查模板。
- 客服回覆模板。
- 週報整理模板。
- 資料分析模板。
- 會議摘要模板。
Prompts 的好處是讓常見任務變得更穩定。
公司可以把常用流程設計成模板，讓 AI 每次處理相似任務時，都能遵循一致的格式與流程。
MCP 跟 API 有什麼不同？
API 是軟體和軟體之間溝通的接口。
例如 Google Calendar API 可以讓程式讀取行事曆，Slack API 可以讓程式發送訊息，GitHub API 可以讓程式查詢 repository。
MCP 背後仍然可能呼叫 API，但它不是單純取代 API。
你可以把 API 想成外部服務本身提供的能力，而 MCP 則是把這些能力包裝成 AI 比較容易使用的工具。
也就是說，AI 應用不用每次都理解每個 API 的細節，而是透過 MCP Server 取得標準化的工具描述、參數格式與回傳結果。
簡單比喻：API 像零件，MCP 則像把零件整理成 AI 可以使用的工具箱。
ChatGPT、Gemini、Claude 怎麼串 MCP？
不同 AI 產品串接 MCP 的方式不完全一樣，但核心邏輯相同：先準備 MCP Server，讓它提供 tools、resources 或 prompts，再讓 AI 應用把這個 Server 加進可用工具清單。
簡單說，MCP Server 是工具與資料的供應端，ChatGPT、Gemini、Claude 則是使用這些工具的 AI 應用端。
差異在於，ChatGPT 比較偏 Apps 與 API 整合，Gemini 比較偏 CLI、coding agent 與開發者工具，Claude 則在 Claude Code、Claude Desktop 與 Connectors 裡提供較直接的 MCP 使用路徑。
ChatGPT 怎麼串 MCP？
ChatGPT 串 MCP 主要有兩種方式：一種是透過 ChatGPT Apps / Apps SDK，把服務做成能在 ChatGPT 裡使用的 App；另一種是透過 OpenAI API，把 remote MCP server 當成工具接進自己的產品。
如果你是一般使用者，看到的通常會是「連接某個 App」或「授權某個服務」。
如果你是開發者，則需要建立一個可連線的 remote MCP server，通常會提供 HTTPS endpoint，讓 ChatGPT 或 OpenAI API 取得工具清單，並在模型判斷需要時呼叫對應 tool。
這種方式適合 SaaS 產品、企業內部助理或自動化流程，但要特別注意授權範圍、資料流向、日誌保存與敏感資訊處理。
Gemini 怎麼串 MCP？
Gemini 的 MCP 串接比較偏向開發者與 coding agent 場景。
如果使用 Gemini CLI，可以在 settings.json 裡設定 mcpServers，讓 Gemini CLI 啟動時連接一個或多個 MCP Server。
例如你可以把 GitHub、資料庫、文件搜尋、內部 API 或設計工具包成 MCP Server，讓 Gemini 在寫程式、查錯、整理文件或執行開發任務時使用。
Google 也提供 Gemini Docs MCP 這類文件型 MCP Server，讓 coding assistant 可以查詢 Gemini API 文件、設定方式與最佳實務。
因此在 Gemini 生態裡談 MCP，最好把它理解成「CLI、coding agent 與開發者工具的外部工具連接方式」，而不是單純等同於 Gemini 網頁版的一個按鈕。
Claude 怎麼串 MCP？
Claude 是最早大量推動 MCP 的 AI 產品之一，因此 MCP 在 Claude 生態裡相對成熟。
以 Claude Code 來說，可以透過指令加入 MCP Server，例如 remote HTTP server、本機 stdio server，或帶有授權 header 的服務。
Claude Code 也支援 local、project、user 等不同層級的 MCP 設定；如果是團隊專案，也可以在專案中放置 .mcp.json，讓團隊共用同一組 MCP Server。
Claude Desktop 則常見於本機 MCP Server，例如連接本機檔案、開發環境或只能在自己電腦上執行的工具。
另外，Claude 也支援 remote connector，讓 Team、Enterprise 或 SaaS 工具把自己的服務變成 Claude 可以使用的連接器。
整體來說，Claude 的 MCP 使用路徑比較清楚，但也因為它能直接讀取工具、資料庫與 API，導入時更要注意權限、提示注入、工具可信度與高風險操作確認。
MCP 的好處
MCP 最大的價值，是把原本分散、客製、難維護的 AI 工具整合，變成比較標準化的連接方式。
對開發者來說，它可以降低重複串接 API、資料庫與工具的成本。
對使用者來說，它讓 AI 有機會取得更貼近現況的上下文，而不是只靠模型記憶回答。
對企業來說，MCP 讓 AI 更容易接上內部文件、資料庫、客服系統、CRM、BI、DevOps 工具與工作流程。
這也讓 AI 從「回答問題」更接近「協助完成任務」。
例如查資料、整理文件、建立任務、產生報表、更新系統或呼叫內部工具。
不過 MCP 不是單純讓 AI 變方便的外掛，而是把 AI 接進真實系統的一層基礎設施。
所以它的好處必須和權限、稽核、資料治理一起看。
MCP 可以拿來做什麼？
MCP 的應用情境很多，可以先抓住一個核心邏輯：AI 需要外部資料或工具時，就可能用 MCP 來連接。
常見場景包括：
- 個人 AI 助理：連接行事曆、信箱、筆記、待辦事項與雲端文件。
- AI Coding：讀取專案檔案、Git history、GitHub issue、錯誤紀錄與測試結果。
- 企業知識庫：查詢 Google Drive、Notion、Confluence、SharePoint 或內部文件。
- 資料分析與 BI：連接資料庫、資料倉儲或報表工具。
- 客服與 CRM：查詢客戶資料、訂單紀錄、過去對話與產品文件。
- 行銷與內容：讀取品牌規範、SEO 關鍵字資料、過去文章與成效報表。
- 設計與產品開發：連接 Figma、產品規格、任務管理工具與程式碼 repository。
- DevOps 與維運：連接監控系統、log 系統、部署工具與 incident management 工具。
- 研究助理：連接文件庫、學術資料來源、引用管理工具與筆記系統。
- 任務型 Agent：連接旅遊、電商、訂票、預約或付款前檢查等服務。
這些場景看起來不同，但本質都一樣：AI 先取得必要上下文，再在授權範圍內協助查詢、整理、建立草稿或執行任務。
只要涉及寄信、付款、部署、刪除、修改客戶資料或更新正式系統，就應該保留人工確認。
新手與工程師要怎麼開始使用 MCP？
如果你不是工程師，不需要一開始就學怎麼寫 MCP Server。
比較實際的做法，是從支援 MCP 或 Apps / Connectors 的 AI 工具開始。
例如：
- 使用支援外部連接的 ChatGPT Apps。
- 使用 Claude Desktop 或 Claude Code 的 MCP 功能。
- 在 Gemini CLI、Cursor、VS Code 等開發工具中使用 MCP。
- 使用企業內部已經設定好的 AI 工具。
新手最重要的是看懂三件事：
- 這個 AI 工具可以連接哪些外部服務？
- 它會讀取哪些資料？
- 它能不能執行會改變資料的動作？
如果只是讀取公開資料，風險相對低。
如果會讀取私人文件、公司資料、客戶資料、API key、資料庫，或能修改外部系統，就要非常謹慎。
如果你是工程師，可以先用現成 MCP Server，例如檔案系統、GitHub、Postgres、Slack、Google Drive 等範例。
先觀察 AI Client 如何列出 tools、如何呼叫 tools、如何回傳結果。
接著可以用 MCP Inspector 測試 tools、resources、prompts，最後再把自己的 API、資料庫或內部工具包成 MCP Server。
建議一開始先做低風險功能，例如查詢資料、列出文件、產生摘要。
等權限控管、日誌、錯誤處理與安全流程比較成熟後，再開放修改資料或執行高風險動作。
延伸閱讀：OpenAI 提供了 Building MCP servers for ChatGPT Apps and API integrations，適合想了解 ChatGPT Apps 與 MCP Server 關係的讀者。
MCP 很強，但不要忽略安全風險
MCP 的能力越強，風險也越高。
因為它讓 AI 可以接觸外部資料、使用工具，甚至執行會改變真實系統狀態的動作。
MCP 官方規格的 Security and Trust & Safety 章節也明確提到，MCP 會帶來任意資料存取與程式執行路徑，因此實作者需要謹慎處理安全與信任問題。
如果權限設計不好，MCP 可能造成資料外洩、錯誤操作、權限濫用、工具投毒、指令注入，甚至供應鏈攻擊。
實務上至少要做到四件事：
- 不要隨便安裝來路不明的 MCP Server。
- 遵守最小權限原則，只給 AI 任務需要的資料與工具權限。
- 高風險動作保留人工確認，例如寄信、付款、刪檔、部署、修改資料庫。
- 留下日誌與稽核紀錄，包含誰連接、讀取什麼、呼叫什麼工具、執行什麼動作。
OWASP MCP Top 10也整理了 MCP 系統常見安全風險，包含 model misbinding、context spoofing、prompt-state manipulation、insecure memory references、covert channel abuse 等問題。
企業導入 MCP 時，不該只由業務單位自行安裝外掛，而應該讓 IT、安全、法務與資料治理一起參與。
如果你想進一步看安全實作細節，可以參考 OWASP MCP Security Cheat Sheet，裡面有最小權限、工具描述完整性、隔離 MCP Server、敏感操作人工確認等建議。
MCP 適合誰？
MCP 對不同角色的價值不太一樣。
對一般使用者來說，你不一定需要知道 MCP 的技術細節，但你需要知道 AI 未來會更常連接你的資料與工具。
你真正要關心的是授權範圍、資料隱私、能不能撤銷權限，以及 AI 在執行重要動作前會不會讓你確認。
對工程師來說，MCP 很值得學。
它可能會成為 AI 工具整合的重要標準，尤其是在 AI Coding、內部工具、自動化流程、資料庫查詢、DevOps 與企業應用裡。
對產品經理與創業者來說，MCP 代表一種新的產品整合方式。
與其只做一個聊天機器人，不如思考你的產品能不能成為 MCP Server，讓各種 AI Agent 可以安全地使用你的資料或工具。
對企業與 IT 團隊來說，MCP 可以幫你標準化 AI 與內部系統的連接方式。
但企業導入 MCP 不該只看效率，也必須同時處理權限、稽核、資料治理與安全邊界。
MCP 不適合什麼情境？
MCP 很有用，但不是所有情況都需要 MCP。
如果你只是問一般知識、寫文章、翻譯、摘要一小段文字，通常不需要 MCP。
如果你只是要做單次資料查詢，可能直接用 API 或 RAG 就夠了。
如果你的組織還沒有基本權限控管、日誌、資料分級、API 管理與安全流程，也不建議一開始就開放高權限 MCP Server。
MCP 是工具，不是魔法。
它可以讓 AI 更有能力，但也會讓錯誤操作與資安問題更有破壞力。
總結
MCP 是 Model Context Protocol，是一套讓 AI 應用標準化連接外部資料、工具與工作流程的開放協議。
它的核心價值，是讓 AI 不只回答問題，而是能在授權範圍內讀資料、用工具、執行任務。
對一般使用者來說，MCP 代表未來 AI 會更像真正的工作助理。
對工程師來說，MCP 可能會成為 AI 應用開發與工具整合的重要基礎。
對企業來說，MCP 有機會讓內部資料、工具與 AI 更容易整合，但前提是權限、稽核、資料治理與安全設計要跟上。
我會建議新手先把 MCP 記成一句話：
MCP 是讓 AI 接上外部世界的標準接口。
它讓 AI 可以連接你的文件、資料庫、工具與系統，但也因為它能接觸更多資料與動作，所以使用時不能只看方便，也要一起重視安全。
MCP 常見問題
MCP 是 AI 模型嗎？
不是。
MCP 不是模型，也不是 ChatGPT、Claude、Gemini 這類大型語言模型。
MCP 是一套協議，讓 AI 應用可以連接外部資料與工具。
MCP 是外掛嗎？
不完全是。
你可以把某些 MCP Server 當成類似外掛的東西，但 MCP 本身是協議，不是單一外掛。
更準確地說，MCP 是讓外掛、工具、資料源與 AI 應用可以標準化溝通的規則。
MCP 一定要會寫程式才能用嗎？
不一定。
一般使用者未來可能只會在 ChatGPT、Claude、Cursor、Gemini 或公司 AI 工具裡看到「連接某個 App」或「授權某個工具」。
但如果你要自己建立 MCP Server，通常就需要工程能力。
MCP 會取代 API 嗎？
不會。
MCP 很多時候會建立在 API 之上。
API 還是外部服務提供能力的基礎，MCP 則讓 AI 應用更容易發現、理解與使用這些能力。
MCP 會取代 RAG 嗎？
不會。
RAG 適合檢索資料，MCP 適合連接工具與工作流程。
兩者可以一起使用。
例如 MCP Server 背後可以使用 RAG 查文件，再把查到的內容回傳給 AI。
MCP 安全嗎？
MCP 本身是一套標準，安全與否取決於實作方式、權限設計、使用者授權、Server 可信度與稽核機制。
如果你隨便安裝不明 MCP Server，或給 AI 過大的系統權限，就可能很危險。
延伸閱讀
- Model Context Protocol 官方介紹：What is MCP?
- Model Context Protocol Specification 2025-11-25
- Anthropic：Introducing the Model Context Protocol
- OpenAI：MCP and Connectors
- OpenAI Apps SDK：Build your MCP server
- Gemini CLI：MCP servers
- Claude Code：Connect to tools via MCP
- OWASP MCP Top 10
- OWASP MCP Security Cheat Sheet
