開場:為什麼需要 MCP?從真實痛點出發
你是一位熱愛學習的工程師,這些年累積了超過 1000 篇個人筆記,散落在本地資料夾裡。涵蓋前端框架、後端架構、演算法、系統設計⋯⋯每一篇都是你花時間整理的寶貴知識。
某天,你想問 ChatGPT:「幫我找所有關於 React Hooks 的筆記,並整理出我還沒掌握的進階用法。」
這個需求聽起來很合理,對吧?但實際上,要讓 AI 助手做到這件事,困難重重。
現有方案都不夠好
讓我們快速看幾個現有的處理方式:
手動複製貼上? 效率極差,每次都要重複,而且 AI 只能看到你貼的部分,無法主動探索更多相關筆記。
批次上傳檔案? 跟剛剛一樣的問題,你得先猜哪些檔案相關,容易遺漏,而且每個新問題都要重新上傳。
用 Claude Code 或 Cursor? 它們的能力被綁死在特定工具裡,而且這些工具就是很會 Coding,不太會討論、發想創意。更重要的是,缺乏標準化 —— 每個工具都自己搞一套。
寫個 REST API? 這是最接近的方案,但有個致命問題:REST API 是為「程式」設計的,不是為「LLM」設計的。 LLM 不知道你有哪些 API,需要每次對話都重新被告知規格,還得自己猜該呼叫哪個 endpoint。
這就是 MCP 要解決的問題。
MCP 是什麼?AI 義肢製作手冊
不知道你有沒有看過 Cyberpunk 2077?
在這個世界觀上,大部分的人都會安裝一推超酷的義肢,更強壯的手臂、更壯的機械腿...,但這些義肢要能正常運作,有個前提:義肢的接口必須符合標準規格。如果每個義肢廠商都自己搞一套接口,那你的手臂根本裝不上去。
MCP 就像是一本「AI 義肢製作手冊」。
ChatGPT、Claude 這些 AI 會根據這本手冊打造對應的「安裝槽」,而任何人都可以根據這份手冊,設計給 AI 使用的「義肢」,然後直接裝上去。
重點來了:MCP 只是一本製作手冊,用嚴謹的話來講就是:
- AI 與工具溝通的標準協定
- 讓 AI 能自動發現工具的機制
- 標準化的權限和安全邊界
它只決定「接口的部分長怎樣」,確保你做出來的義肢可以順利裝到其他 AI 身上。至於這個義肢有什麼功能?讀檔案、查資料庫、發 email、控制你的智慧家居⋯⋯隨便你,完全自由。
與 REST API 的差異
MCP 是為 LLM 設計的標準化協定,讓 AI 能夠自動發現和使用你的工具。
關鍵差異:
| 特性 | REST API | MCP | 
|---|
| 設計對象 | 給「開發者」用 | 給「LLM」用 | 
| 發現機制 | 需要讀文件 | AI 自動發現工具 | 
| 使用方式 | 需要寫程式呼叫 | AI 自動選擇並呼叫 | 
| 參數格式 | 需要查文件 | 設計 MCP 時,都會定義好 | 
在提到 MCP 之前,必須得提一下什麼是 「Agent」?
這裡快速釐清一下概念。
AI(嚴格來說是 LLM)就是一個只會思考、無法行動的大腦。
對,他只是一顆大腦,沒手沒腳,無法行動。他可以思考得很深入、很精彩,但你問他「幫我查一下天氣」,他只能回答「抱歉我查不了」。
那什麼是 Agent 呢
簡單說,Agent = AI 大腦 + 能力(工具)。給 AI 裝上「手」(查天氣的工具)、「腳」(控制智慧家居的工具),他就從一顆只會想的大腦,變成一個能實際做事的 Agent。
MCP 就是定義「怎麼給 AI 裝義肢」的標準。
如果你對 AI Agent 的概念想要更深入了解,推薦閱讀我之前撰寫的書籍《從零開始,打造一個生成式 AI 平台》https://www.books.com.tw/products/0011029234 ,裡頭有更完整的講解。
如果說 AI 的大腦是語言模型,那麼 Tools 就是 AI 的義肢。
沒有義肢,大腦再聰明也只能思考,無法行動。有了 Tools,AI 才能:
- 獲取資訊 — 讀取你的檔案、查詢資料庫、呼叫 API
- 執行動作 — 發送郵件、建立文件、修改資料
- 改變狀態 — 更新設定、記錄日誌、觸發流程
1. AI 自己決定什麼時候用
這是 Tools 最重要的特性。你不需要明確指示「請呼叫 XXX 工具」,AI 會根據對話情境自己判斷。
AI 自己決定:
2. Tool 本質就是一個 Function
Tools 就是一個 Function,他執行完後的結果,會送回給 LLM
就像下面這三個 Function
- list_notes()→ 返回:[note1.md, note2.md, note3.md]
- read_note(path: "note1.md")→ 返回:筆記的完整內容
- search_notes(query: "React")→ 返回:包含 "React" 的筆記列表和摘要
每個 Tool 的呼叫都會產生結果,AI 會根據結果決定下一步動作。
這就像是你問助理「幫我查一下檔案」,他真的會去翻檔案櫃。
3. 有明確的規格書(Schema-Defined)
每個 Tool 都有清楚的說明書,你必須替每一個工具定義好以下參數
- 工具名稱,這個工具叫什麼
- 工具說明,這個工具是做什麼的
- 輸入參數,這個工具可以傳入什麼,需要提供什麼參數
- 輸出參數,這個工具會回傳什麼
基本上還是剛剛提到的,Tool 的本質就是一個 Function,只是你必須詳細交代 LLM 該怎麼用、什麼時會去用這個 Function