MCP 是什麼？像替 AI 工具接上一種共通插座，讓模型更容易連資料與外部能力

你做一個 AI Agent，想讓它可以：

• 查 GitHub
• 讀公司文件
• 查 Database
• 操作本機檔案
• 呼叫內部 API

以前每接一個系統，都可能要寫一套不同 Integration。

Model Context Protocol（模型上下文協定，MCP） 想解決的，就是這個「每個工具都要自己做轉接線」的問題。

先用插座理解 MCP

想像世界上每一台電器都用完全不同插頭。

你買一台新家電，就要請水電工重新拉線。

MCP 的方向比較像：

定義一種共同的連接規格，讓支援這個規格的 AI Host 和工具服務能比較一致地互通。

它不是保證所有工具功能都一樣，而是先把「怎麼互相說話」標準化。

MCP 不是模型

這是最常見誤解。

MCP ≠ LLM
MCP ≠ Agent
MCP ≠ Database

MCP 是 Protocol（協定）。

就像 HTTP 不是網站內容，而是系統溝通使用的一套規則。

三個角色：Host、Client、Server

MCP 官方規格常用三個角色。

Host

Host（主機應用） 是使用者真正操作的 AI 應用。

例如 AI IDE、Desktop Agent、Chat App。

Client

Client（客戶端） 是 Host 裡負責和特定 MCP Server 建立連線的部分。

Server

Server（伺服器） 則對外提供能力與 Context。

概念上：

AI App / Host
  ↓
MCP Client
  ↓
MCP Server
  ↓
Files / GitHub / Database / Internal Service

MCP Server 可以提供什麼？

MCP 的 Server Primitives（伺服器基本能力）包含幾個重要類型。

Tools

Tools（工具） 是模型可以呼叫的動作。

例如：

search_issues
create_ticket
query_database

這和 Lesson 020：AI Agent 的 Tool Calling 概念直接接在一起。

Resources

Resources（資源） 是可以提供給模型的資料或 Context。

例如：

• 檔案內容
• Git History
• 文件
• 設定資訊

Prompts

MCP 也能提供預先定義的 Prompt / Workflow Template。

為什麼開發者很喜歡這個方向？

假設沒有共通 Protocol：

App A × GitHub：做一次 Integration
App A × Database：再做一次
App B × GitHub：又做一次
App B × Database：又做一次

支援 MCP 後，理想上可以降低很多重複接線成本。

這也是為什麼 MCP 在 Coding Agent 和 Agent Tooling 裡很熱門。

MCP 和 API 有什麼關係？

Lesson 018：API 已經講過 API 是系統提供能力的接口。

MCP 不會讓既有 API 消失。

很多 MCP Server 本身就是：

收到 MCP Tool Call
→ 轉去呼叫某個 API
→ 把結果整理回來

所以 MCP 更像是 AI 應用上層的一致介面。

共通標準不等於自動安全

這點非常重要。

如果一個 MCP Server 暴露：

delete_database

那它不會因為「使用 MCP」就突然安全。

你仍要考慮：

• Authentication
• Authorization
• 哪些 Tools 可以用
• 參數驗證
• Secret Isolation
• Human Approval
• Audit Log

這和 Lesson 036 的 Guardrail 分層 是同一個觀念。

遠端 MCP 也代表資料會離開原本環境

如果你把公司資料送給第三方 Remote MCP Server，那些資料就進入另一個服務的資料處理範圍。

所以接 Server 前要問：

• 誰營運？
• 傳什麼資料？
• 保存多久？
• 有哪些權限？
• 是否真的需要寫入能力？

不要把「安裝 MCP Server」理解成安裝普通 UI Plugin 那麼簡單。

一句話帶走

MCP 是一個讓 AI 應用以較標準化方式連接 Tools、Resources 與外部資料的開放協定。它像共通插座，能降低每個 Integration 都重新接線的成本；但接上什麼能力、給多少權限、資料送去哪裡，仍然是你的安全責任。