Agent 與 MCP
MCP 是什麼？一次搞懂 AI 應用的萬用接頭
MCP 是什麼？一次搞懂 AI 應用的萬用接頭
你大概已經在很多地方看過 MCP（Model Context Protocol）這個縮寫：Claude 的桌面應用可以接 MCP、各種開發工具可以接 MCP，彷彿什麼都能接。但它到底是什麼？一句話講完：MCP 是一層溝通協定，讓 Claude 拿到外部的脈絡與工具，而你不必再寫一堆瑣碎的整合程式。
這篇文章帶你從一個具體的例子出發，看懂 MCP 解決什麼問題、client 與 server 怎麼分工，以及一個使用者提問從頭到尾的完整旅程。
你將學到什麼
MCP 解決什麼問題
從一個 GitHub 聊天機器人的例子，看整合負擔有多重。
client 與 server 的分工
誰負責溝通、誰負責實作，一張圖看懂。
MCP 與 tool use 的差別
最常見的誤解：兩者互補，但不是同一件事。
一個提問的完整旅程
從使用者提問到 Claude 回答，訊息怎麼流動。
從一個 GitHub 聊天機器人說起
假設你要做一個聊天介面，讓使用者問 Claude 自己的 GitHub 資料，例如「我所有的 repo 裡有哪些還開著的 pull request？」。要回答這種問題，Claude 需要能存取 GitHub API 的工具。
問題來了：GitHub 的功能非常龐大，repo、pull request、issue、project 一路數下去。沒有 MCP 的話，每一項功能你都得自己做一個工具：一份 schema 定義，加一個真正去打 API 的函式。想做出完整的 GitHub 聊天機器人，你得寫出數量驚人的工具，而且每一個都要自己測試、自己維護。
而這還只是一個服務：等你想再接上行事曆、雲端硬碟、內部資料庫，同樣的苦工要再來幾輪，維護負擔跟著服務數量一路往上疊。
MCP 怎麼解決：把整合的工搬走
MCP 的解法很直接：把工具的定義與執行，從你的伺服器搬到專門的 MCP server 上。你不再自己寫 GitHub 工具，而是接上一個包好 GitHub 功能的 MCP server，裡面的工具早就有人寫好、測好了。
MCP server 的角色，就是外部服務的標準化介面：它把複雜的整合包成可重複使用的元件，任何應用都能接上來用。誰來寫這些 server？任何人都可以。實務上很常見的是服務商自己出官方版本，例如雲端服務商替自家各項服務釋出官方 MCP server。你想接的服務，很可能已經有現成的 server 在等你。
最常見的誤解：MCP 不等於 tool use
第一次接觸 MCP 的人，十個有九個會問：「這不就是 tool use 嗎？」不是，兩者互補但不同。tool use 講的是 Claude 怎麼呼叫工具；MCP 講的是工具由誰來寫、由誰維護。接上 MCP server，代表 schema 與函式都已經有人幫你完成，打包在 server 裡了。
跟直接呼叫 API 的差別也在這裡：直接打 API，工具定義全部自己來；走 MCP，這些實作工作全部省下。你維護的不再是一大包整合程式，而是一條接向 MCP server 的連線。
那我還需要學 tool use 嗎？需要。Claude 判斷何時呼叫工具、你把結果回填給它，這條迴圈完全不變；MCP 改變的只是工具從哪裡來。一句話總結：tool use 是機制，MCP 是供應鏈。
client 與 server 怎麼講話
你的應用裡負責跟 MCP server 溝通的元件叫 MCP client：它是你通往所有工具的入口，訊息傳遞與協定細節都由它處理。MCP 的一大優點是 transport agnostic：client 與 server 可以用不同的通道溝通。最常見的是兩者跑在同一台機器上，用標準輸入輸出對話；也可以走 HTTP、WebSocket 這類網路協定。
連上之後，兩邊交換的是 MCP 規格定義好的訊息類型，最主要的兩組是：
- ListToolsRequest / ListToolsResult：client 問 server「你提供哪些工具？」，拿回工具清單。
- CallToolRequest / CallToolResult：client 請 server 用指定的引數執行某個工具，拿回執行結果。
訊息類型不只這兩組，但九成的互動就靠它們：先問對方有什麼工具，再請對方執行。之後你自己實作 client 時會發現，SDK 早已把這些訊息的組裝與解析包好，你呼叫的只是 list_tools 與 call_tool 這樣的方法。
一個提問的完整旅程
把所有角色串起來，看「我有哪些 repo？」這個問題怎麼流動：
- 使用者把問題送進你的應用。
- 你的應用透過 MCP client 向 MCP server 要工具清單（ListToolsRequest）。
- 你的應用把問題加上工具清單，一起送給 Claude。
- Claude 判斷需要呼叫工具，回覆一個 tool use 請求。
- 你的應用請 MCP client 執行該工具（CallToolRequest），MCP server 實際去打 GitHub API。
- 結果一路回傳：GitHub → MCP server → MCP client → 你的應用。
- 你的應用把工具結果補送給 Claude，Claude 整理出最終回答，再由你的應用回給使用者。
步驟看起來多，但每個元件的責任都很清楚：MCP client 把 server 溝通的複雜度收乾淨，你只要專心寫應用邏輯。對使用者來說什麼都沒變，還是問一句話拿一個答案；對你來說，整條工具供應鏈換了人維護。這也是為什麼 MCP 生態一起來，「接工具」就從苦工變成了選型。想再深入，可以逛官方網站 modelcontextprotocol.io。
延伸學習
ChatGPT 很強，但真正讓你下班的是 Google
六小時完整實錄。從「AI 很厲害，為什麼你還是每天加班」這個問題出發，把 Google Workspace 當成真正的工作平台重新設計一次流程 ── Sheets 的資料結構、Drive 與 Docs 的文件流、Gmail 與 Calendar 的通知系統，再用 Apps Script 讓它自己跑起來，最後收斂成一張屬於你自己的 AI 工作能力地圖。
NT$ 4,599
HE101｜Harness Engineering Foundation（3 小時）
三小時的地圖課，不是操作課。把 Model 與 AI System 分開，拆解一套 AI Harness 的八個組成（Goal、Context、Knowledge、Rules、Tools、Workflow、Evaluation、Iteration），再帶你逆向拆解四個你已經在用的系統，最後畫出自己的第一張 Harness Blueprint。5 章 27 課，附學員講義 PDF 與術語速查表。
NT$ 2,599