MCP 入門：為什麼需要 Model Context Protocol
從「LLM 幫我請假」這個內部系統情境出發，看 N × M 整合災難為什麼存在、MCP 怎麼把它變成 N + M。
TL;DR
- 沒有標準前，M 個 App × N 個工具 = N×M 條整合——同一份工具會被不同團隊各自重寫一次。
- MCP（Model Context Protocol）把工具的 schema 跟執行邏輯從 App 搬到專門的 MCP Server，整合數從 N×M 降到 N + M。
- 一個 MCP Server 寫好，所有支援 MCP 的 host 都能用——這個解耦跟 LSP（Language Server Protocol）讓編輯器與語言工具解耦是同樣的策略。
一個情境：LLM 幫我請假
公司用內部 HR 系統管請假——查餘額、送單、找人簽核都在裡面。沒人會出 SaaS 版的 MCP 給你，因為這就是貴司自己的東西。
員工的痛點通常很雜：
「下週三、四想請假，幫我看餘額還夠不夠，順便確認我主管那兩天有沒有檔期可以批。」
這一句話拆出三個動作：
- 查我的特休餘額
- 查主管那兩天的行事曆
- 送出請假申請
要讓 LLM 幫你做完，它需要呼叫 HR 系統的工具。問題就從這裡開始。
沒有 MCP 你會卡在哪
每加一個系統都要寫一輪：
- 每個動作寫一個
toolschema 給 LLM 看（名稱、參數、描述） - 每個 tool 寫對應的 function：打 HR API、處理錯誤、處理 auth
- 然後 IT 工單系統、會議室預訂、報銷……每個都來一次
更慘的是這些東西寫完之後，只有你的 App 用得到。隔壁團隊做別的 LLM 應用——員工 portal、Slack bot、客服 chatbot——又得自己再寫一次同一份 HR 工具。
N × M → N + M
把這件事畫出來就更清楚。假設公司有 M 個 LLM 應用要用 N 個內部系統：
| 沒 MCP | 有 MCP | |
|---|---|---|
| 整合數 | N × M | N + M |
| 多一個工具 | M 個 App 都要改 | 寫一個 Server 就完事 |
| 多一個 App | 要重新串 N 個工具 | 連上現有 Server 即可 |
差一個乘號跟一個加號，但乘號是過去三年 LLM 應用開發的「基礎建設稅」——大家都在做同樣的接線工，沒人在累積。
MCP 把責任搬走
核心想法很簡單：工具的定義跟執行不該住在你的 App 裡。
把它搬到「專門的 MCP Server」：
- HR MCP Server：包好
get_leave_balance、request_leave、approve_leave，內部接 HR API - 行事曆 MCP Server：包好
find_free_time、list_events - 每一個都是獨立的程序，獨立部署，獨立維護
你的 App 只要當個 Client 連上去用就好。隔壁團隊也連得到。寫一次，整個公司用。
通常擁有那套系統的團隊就是 MCP Server 的維護方：HR 平台組維護 HR MCP Server、IT 平台組維護 IT 工單 Server。各應用團隊（Slack bot、員工 portal、客服 LLM）都連同一份 server，工具邏輯一處改、全部受惠。
生態系效應
公司內部省下重複工是第一層；MCP 真正的槓桿在於——這個解耦在公司外也成立。
任何人寫一個 Postgres MCP Server，所有支援 MCP 的 host 都能立刻用：
| 你寫了 | 立刻可用於 |
|---|---|
| Postgres MCP Server | Claude Desktop、Cursor、Cline、Zed... |
| GitHub MCP Server | 任何 MCP host |
這個策略跟 LSP（Language Server Protocol） 讓編輯器與語言工具解耦完全一樣——VSCode、Vim、Emacs 不用各自實作 TypeScript / Python / Go 的 language server，寫一次大家都能用。
2025 年 OpenAI 在 ChatGPT 與 Agents SDK 也宣佈支援 MCP，MCP 正式成為跨 provider 標準。這也是為什麼這一系列文章把 MCP 標記為 Anthropic 跟 OpenAI 共用主題。
接下來
下一篇拆 MCP 的三個角色（App / Client / Server）、Server 能暴露的三種東西（Tools / Resources / Prompts），跟 transport 為什麼可以隨便挑。