MCP 架構：三角色與 capabilities

TL;DR

• 三個角色：你的 App ↔ MCP Client ↔ MCP Server，職責切得很乾淨——App 編排對話，Client 講協定，Server 實作工具。
• Server 能暴露三種 capabilities：Tools（可呼叫的函式）、Resources（可讀取的資料）、Prompts（寫好的樣板）。
• Client / Server 之間 transport-agnostic——同機 stdio、跨機 HTTP、長連線 WebSocket 都行，SDK 抽象掉了。

三個角色

最基本的拓樸：

職責切得很清楚：

角色	負責	在 HR 範例裡
你的 App	跟 LLM 對話、組 prompt、決定何時叫工具	員工聊天介面、Slack bot
MCP Client	講 MCP 協定、把訊息送出去、收回來	嵌在你 App 裡的 SDK
MCP Server	暴露工具、實作每個工具的真正邏輯	包 HR API 的獨立程序

Client 通常是個 SDK，你 import 進來就用；Server 通常是另一個獨立程序，由 MCP Client 透過 stdio / HTTP 啟動或連線。

職責切乾淨之後，寫 App 就不用碰 HR API，寫 Server 就不用管 LLM 怎麼決策。

不只 Tools — 還有 Resources 跟 Prompts

MCP Server 暴露的東西不只是 tools，總共三種：

• Tools：LLM 可以呼叫的函式（request_leave）
• Resources：可以被讀取的資料（leave_policy.md、團隊行事曆）
• Prompts：寫好的 prompt 樣板（draft_leave_request）

每個 capability 都有 schema，Client 在連上 Server 時詢問支援什麼。這個系列先聚焦在 Tools，後面幾課會再回來看 Resources / Prompts 怎麼用。

Transport-Agnostic：用什麼通道都行

MCP 沒規定 Client 跟 Server 之間怎麼連線：

傳輸	適合
stdio（最常見）	同機、零網路設定、SDK 啟動 server 子程序
HTTP	跨機、SaaS 形態、需要 auth
WebSocket	長連線、雙向 push

寫應用時你不用管選哪個——SDK 會抽象掉。HR Server 自己跑在公司 K8s 上、走 HTTP 也行；放在開發者本機跑、走 stdio 也行。

各 transport 細節留到「架構」section 的 stdio / HTTP 兩篇。

容易搞混的觀念

「這跟 function calling 不是一樣嗎？」

不一樣，但互補。

• Function calling 是 LLM 廠商給的能力——「我會輸出結構化的 tool call 指令」。
• MCP 是工具的「供應鏈協定」——「工具的 schema 跟執行從哪來、怎麼傳」。

LLM 還是用 function calling 決定要不要呼叫工具；MCP 補上的是「工具是誰寫、住在哪裡、怎麼連」這層。

「跟直接打 API 比起來呢？」

直接打 API 你要自己寫 schema、自己包工具。MCP Server 是直接撿別人寫好的（內部系統就是 IT/平台組寫一次給全公司用）。省的是實作工，不是延遲或自由度。

「誰來寫內部系統的 MCP Server？」

通常是擁有那套系統的團隊：HR MCP Server 由 HR 平台組維護、IT 工單 MCP Server 由 IT 維護。各應用團隊（Slack bot、員工 portal、客服 LLM）都連同一份 server，更新工具邏輯一處改、全部受惠。

接下來

知道角色跟 capabilities 之後，下一篇看 Client 跟 Server 之間實際在傳什麼訊息——ListTools 跟 CallTool 怎麼跑完一個請求。