AI Agent：打造你的第一個 MCP Server：從概念到實作

Ray 貓

2025/10/28 更新2025/10/28 發佈閱讀 7 分鐘

你也可以在我的部落格中 https://blog.ray-realms.com/article/73b7d4c5-fc5e-49e2-a7df-c675c4703300 閱讀此文章

開場：為什麼需要 MCP？從真實痛點出發

你是一位熱愛學習的工程師，這些年累積了超過 1000 篇個人筆記，散落在本地資料夾裡。涵蓋前端框架、後端架構、演算法、系統設計⋯⋯每一篇都是你花時間整理的寶貴知識。

某天，你想問 ChatGPT：「幫我找所有關於 React Hooks 的筆記，並整理出我還沒掌握的進階用法。」

這個需求聽起來很合理，對吧？但實際上，要讓 AI 助手做到這件事，困難重重。

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 能夠自動發現和使用你的工具。

關鍵差異:

MCP vs REST API

在提到 MCP 之前，必須得提一下什麼是「Agent」?

這裡快速釐清一下概念。

AI（嚴格來說是 LLM）就是一個只會思考、無法行動的大腦。 對，他只是一顆大腦，沒手沒腳，無法行動。他可以思考得很深入、很精彩，但你問他「幫我查一下天氣」，他只能回答「抱歉我查不了」。

那什麼是 Agent 呢 簡單說，Agent = AI 大腦 + 能力（工具）。給 AI 裝上「手」（查天氣的工具）、「腳」（控制智慧家居的工具），他就從一顆只會想的大腦，變成一個能實際做事的 Agent。

MCP 就是定義「怎麼給 AI 裝義肢」的標準。

如果你對 AI Agent 的概念想要更深入了解，推薦閱讀我之前撰寫的書籍《從零開始，打造一個生成式 AI 平台》https://www.books.com.tw/products/0011029234 ，裡頭有更完整的講解。

MCP 的核心概念：Tools — AI 的「義肢」

如果說 AI 的大腦是語言模型，那麼 Tools 就是 AI 的義肢。
沒有義肢，大腦再聰明也只能思考，無法行動。有了 Tools，AI 才能：

獲取資訊 — 讀取你的檔案、查詢資料庫、呼叫 API
執行動作 — 發送郵件、建立文件、修改資料
改變狀態 — 更新設定、記錄日誌、觸發流程

Tools 的三個關鍵特性

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

❓ 練習題

你正在開發一個「個人知識庫」的 MCP Server。下列哪個功能「不應該」設計成 Tool？

A) 搜尋筆記內容（根據關鍵字找出相關筆記）
B) 筆記分類規則（說明你如何組織筆記的 markdown 文件）
C) 建立新筆記（在指定目錄建立 .md 檔案）
D) 統計筆記數量（計算各分類有多少筆記）