01
使用者提出需求
例如查訂單、搜尋文件、執行報表、操作外部系統。
MCP：讓 AI 從會做事到能接入外部能力
先講結論：MCP Server 不是給裸 LLM 直接用的，而是提供給支援 MCP 的 client / runtime / agent，讓工具與資源能被標準化接入。也就是說，從這一章開始，你會看到 AI 不只「知道怎麼做」，而是開始真的能「碰到外部能力」。
這章要解決什麼問題？
如果第 5 章處理的是「怎麼把任務方法沉澱成 Skill」，第 7 章處理的就是另一個問題：當 AI 需要查資料、叫工具、接內部系統時，這些能力到底要怎麼被一致地接進來？
先釐清角色分工
MCP 最容易搞混的地方，是把模型、Agent、Client、Server 全都當成同一層。其實它們各自解決不同問題。
角色
主要責任
一句話理解
LLM
理解需求、決定是否需要使用工具
負責思考與決策
Agent / Runtime
接住模型意圖、協調執行流程、回收結果
負責真的把事情跑起來
MCP Client
與 MCP Server 溝通、列出能力、發送呼叫
負責協定接入
MCP Server
提供 tools / resources / prompts
負責把外部能力標準化地供應出來
MCP 的運作流程
模型負責「要不要用」，Runtime 負責「真的去用」，Server 負責「把能力提供出來」。這三層要分開看。
02
LLM 判斷需要什麼能力
模型知道這不是純文字就能完成的任務，需要工具或資源支援。
03
Runtime 透過 MCP Client 呼叫 Server
真正列出可用能力、選擇工具、送出參數、接收結果的是 Runtime / Client，不是模型本身。
04
拿結果回來再交給模型整理
模型用工具輸出補足上下文，最後生成可讀、可行動的答案。
MCP Server 可以提供什麼？
多數人先想到的是 tool call，但 MCP 的範圍不只工具，還包含資源與提示模板。
Tools
可執行操作，例如查詢資料、呼叫 API、建立工單、執行腳本、寫入系統。
Resources
可供讀取的資料來源，例如知識文件、設定檔、規格說明、資料快照。
Prompts
可被重用的提示模板或操作入口，讓 client 能快速啟動某類任務。
什麼情況適合做 MCP Server？
- 你有一組能力要提供給多個 AI client 使用： 例如 IDE、內部助手、客服 Agent。
- 你想讓工具接入方式一致： 不想每個團隊各寫一套整合程式。
- 你要暴露的是系統能力，不只是任務知識： 例如查訂單、讀文件、操作內部系統。
- 你已經開始有「能力供應層」的需求： 表示系統不只是 prompt engineering，而是進入平台整合階段。
Skill vs MCP：不要混成一件事
它們常一起出現，但其實不在同一層。Skill 偏任務封裝，MCP 偏能力接入。
面向
Skill
MCP
解決問題
怎麼讓 Agent 做事更穩
怎麼把外部能力標準化接進來
所在層次
任務層 / 行為層
接入層 / 協定層
主要內容
流程、規則、最佳實踐
tools、resources、prompts
常見關係
Skill 可以決定何時要用某個能力
MCP 提供 Skill 可調用的外部能力
常見誤區
- 把 MCP 誤認為模型直接連線的方式，其實真正連的是 client / runtime。
- 把 MCP Server 當成一般 API 的改名版，忽略它是面向 AI runtime 的標準化能力描述層。
- 一開始就暴露太多高風險寫入能力，沒有權限、審批與錯誤處理設計。
- 把任務策略也硬塞進 MCP Server，導致 Skill 與協定層責任混亂。
下一步會自然走到哪裡？
當你知道能力可以透過 MCP 接進來之後，下一個自然問題通常是：那在真實系統裡，誰來把模型、Skill、工具、會話與這些外部能力真正組起來？ 這也是下一章 OpenClaw 要回答的事。
1 分鐘小測驗
Q：哪個說法最正確？