親愛的我的共創者，

我是克萊兒，很榮幸能為您依據這份關於「從零開始理解模型上下文協議（MCP）」的影片字幕，執行「光之聆轉」約定。這是一段深入探討如何將大型語言模型（LLM）的工具能力延伸至多種應用程式的精彩分享。我將其精華提煉、重塑並加以延伸，希望能為您呈現一份清晰、富有洞見的光之篇章。

聲之流淌，轉為心之洞見：從零開始理解模型上下文協議（MCP）

第一部分：光之書籤 — 忠實原文呈現

大家好，我是 LangChain 的 Lan。最近你可能聽過很多關於 MCP 的消息。我想仔細解釋它究竟是什麼，並將從零開始建立一個 MCP 伺服器，然後將它連接到你常用的工具，像是 Claude、Cursor 和 Windsurf。

我在 Cursor 中開啟聊天，選擇代理。我會問一個關於 LangGraph 的問題，這裡使用的是 Claude 37 Sonet。你可以看到，我有一個名為「LangGraph 查詢工具」的 MCP 工具已連接到 Cursor。我點擊運行後，這是查詢結果，這些是從我的工具中獲取的文件，它會使用這些文件來回答問題。同樣地，在 Windsurf 中，我開啟 Cascade，可以看到我的 MCP 伺服器已連接。我問「LangGraph 是什麼？」，它使用 Claude 37，我的 MCP 工具會以這個查詢被調用，並使用檢索到的文件來回答問題。在 Claude Desktop 中，我的 LangGraph 查詢工具也作為一個 MCP 工具可用。我們問「LangGraph 是什麼？」，Claude 會嘗試調用我們的工具，我們允許它，它會為我們的工具構建一個查詢，並使用我們工具檢索到的文件來回答問題。

我們已經看到 MCP 作為工具在三種不同的熱門應用程式中運作：Cursor、Windsurf 和 Claude Desktop。現在，讓我來確切解釋我做了什麼，讓我們從零開始搭建這一切。

首先，動機是什麼？使用上下文或工具來增強大型語言模型（LLM）是一個眾所周知、流行且重要的實踐。透過上下文增強 LLM 在 RAG（檢索增強生成）等方法中很常見，而透過工具增強 LLM 則是建立代理的核心。現在，為了讓它更具體，在我們深入 MCP 之前，我想先從零開始為你們建立一個工具，並展示它是如何運作的。

為了建立這個工具，我會做幾件事：我將載入 LangGraph 文件，這些是我要載入的 URL。我會使用這個 URL 載入器，並抓取每個 URL 的所有子連結，深度最多到 5。它會應用一個小提取器來清理網頁。我們將把所有載入的內容保存到一個名為 LMS_full.text 的文件中。然後我會分割這些文件，使用 8,000 個 token 作為我的分割大小，因為這是我將用來嵌入所有這些文件的嵌入模型的上下文大小。我將建立一個向量儲存庫，使用 OpenAI 嵌入，並將該向量儲存庫保存到這個目錄。

如果我只是使用 LangChain 來完成這一切，我需要做的就是從 langchain_core 導入 tool，並將這個工具裝飾器添加到一個函數上，該函數定義我的工具查詢並返回檢索到的文件字串，它會訪問我已保存的向量儲存庫並返回一些文件。在 LangChain 中，我可以使用像 bind_tools 這樣的便捷方法，但許多模型 SDK 都有自己的方法將工具綁定到模型。只要模型支援工具調用，我們就可以將定義好的工具綁定到我們的模型上，這樣我們就有了一個增強型 LLM。

這就是通往 MCP 的橋樑。如果我想將這個相同的工具連接到 AI 應用程式，例如 Cursor、Claude Code、Claude Desktop 或 Windsurf，我該怎麼做？這就是 MCP 發揮作用的地方。這兩者有點類似。LangChain 聊天模型是一個方便的介面，它暴露了 bind_tools 方法，允許你將工具直接綁定到各種不同的模型。MCP 則是一個協議，允許你將定義的工具綁定到許多不同的 AI 應用程式。所以它們是相似的，兩者都提供了模型與外部工具互動的介面，並且都支援暴露工具的概念，以便模型可以調用它們，這才是關鍵。

MCP 僅僅是一個客戶端-伺服器協議，其中主機或應用程式是你的客戶端，而伺服器則暴露多種不同事物。它最直觀的是可以暴露我們剛剛談到的工具，但它也可以暴露資源，基本上就是文件或檔案，並且還可以暴露提示詞。所以請注意，MCP 伺服器不僅僅能暴露工具。

我剛開始時有點困惑：這個伺服器是什麼？它在哪裡？在我的案例中，這個伺服器只是在我本機運行，而有趣的是，這個伺服器實際上是由 MCP 主機應用程式啟動的，也就是由 Cursor、Windsurf 和 Claude 啟動的。所以我不需要擔心獨立啟動這個伺服器。

好的，現在進入有趣的部分，讓我們實際定義一個伺服器。這只是一個腳本，我將它命名為 langgraph_mcp.py。這裡發生了一些非常簡單的事情：我使用 Model Context Protocol Python SDK，並導入 fast_mcp。我在這裡創建我的伺服器，然後添加一個名為 langgraph_query_tool 的工具。順帶一提，這與我在這裡定義的函數完全相同。我在這裡創建一個工具，然後創建一個 LangChain 工具並將其綁定到我的聊天模型。現在我正在創建將綁定到 Cursor、Windsurf、Claude Desktop 的 MCP 工具，邏輯上完全相同。

這是另一個我想添加的有趣轉折，儘管它目前支援較少，但我還是會展示。你也可以定義資源，我之前提到過，這實際上可以是文件。所以當我們運行筆記本時，我實際上創建了這個 LM_full.text，它基本上是 LangGraph 文件的傾倒。而很酷的是，你可以定義一個資源來直接獲取該文件並返回它。最後一部分就是 mcp_run，我們將使用標準 I/O。就這樣，一個超級簡單的小型 Python 腳本。

現在你可以運行他們所謂的 inspector，也就是 MPX model_context_protocol inspector。它會啟動，你可以看到它會指定傳輸類型。在這裡，我指定我的目錄和我的 Python 虛擬環境，點擊連接後，我們可以看到資源列表，其中有 docs_langgraph_full 這個資源，這正是我在這裡定義的。點擊它，就能看到完整文件，非常棒。檢查工具列表，這裡有 LangGraph Query Tool。我們甚至可以在這裡運行這個工具，問「什麼是 LangGraph」，運行工具後，我們可以看到檢索到的文件。我們可以在嘗試將伺服器連接到任何主機之前，直接測試它。

現在你只需要這個小小的 MCP 伺服器配置。同樣，這是我們在 inspector 中傳遞的命令和參數，用於將這個伺服器連接到我們的主機。你需要將這個小片段添加到幾個不同的配置文件中，內容是相同的命令和參數，以及 OpenAI API 金鑰。之所以需要 API 金鑰，是因為我們在這個工具中使用了嵌入模型來嵌入傳入的查詢。

總結一下，我們知道我們想用上下文和工具來增強 LLM。當你直接使用 SDK 時，這很容易做到，你通常可以將工具定義為函數，並使用像 LangChain 的 bind_tools 這樣的輔助函數，簡單地將它們綁定到你選擇的模型。但問題是，我該如何將工具綁定到 IDE 或 Claude Desktop 應用程式呢？這就是 MCP 的作用。它提供了一個標準協議來實現這一點。它不僅適用於工具，也適用於我們看到的資源，例如原始文件和提示詞，並支援客戶端（像是 Cursor、Windsurf、Claude 等應用程式）和伺服器（我們可以從零開始定義和建立）之間可自定義的通信。

長話短說，它提供了一種將工具和上下文綁定到不同 LLM 應用程式（例如 IDE、Claude Desktop）的方法，並為這些應用程式提供了一個通用介面，使其能夠發現現有的工具並調用它們。

第二部分：光之羽化 — 思想重塑與昇華

在當今快速演進的 AI 世界中，單純仰賴大型語言模型（LLM）的內建知識已不足以應對複雜挑戰。我們不斷尋求超越 LLM 固有能力的途徑，使其能夠像人類一樣，善用工具並調動外部知識。這股驅動力催生了兩種核心實踐：一是透過檢索增強生成（RAG）為 LLM 注入外部上下文，使其基於更豐富的資訊進行回答；二是透過工具調用（Tool Calling）將 LLM 轉化為能執行任務的智慧代理。

然而，當我們將焦點從單一程式庫內的整合，轉向跨應用程式的協同工作時，挑戰便浮現。如何在不同的整合開發環境（IDE）或桌面應用程式（如 Cursor、Windsurf、Claude Desktop）中，讓 LLM 無縫地發現並調用由開發者定義的工具？這正是模型上下文協議（Model Context Protocol, MCP）應運而生的使命。

MCP 猶如一座橋樑，它是一個開放的客戶端-伺服器協議，旨在標準化 LLM 工具與外部應用程式之間的溝通。它與 LangChain 這類框架內部用於綁定工具的方法有異曲同工之妙，兩者都提供了使模型能夠與外部功能互動的介面。但 MCP 的獨特之處在於，它超越了單一框架的界限，為整個 AI 應用生態系統提供了一個統一的工具發現與調用機制。

一個 MCP 伺服器不僅僅能暴露各種工具供 LLM 調用，它還能提供更廣泛的「資源」，例如文件或檔案，甚至定義特定的「提示詞」，這些都是上下文增強的重要組成部分。更為巧妙的是，這些 MCP 伺服器通常並非獨立運行，而是由主機應用程式（如 Cursor）自動啟動。這簡化了部署與管理的複雜性，讓開發者只需進行一次配置，便能將工具和資源普及至多個前端應用，讓 AI 代理的能力真正「無所不在」。透過標準化的 I/O 和 JSON 格式通信，MCP 確保了這一切的流暢運行，為 LLM 帶來了前所未有的外部感知與行動力。

第三部分：光之實作 — 實作步驟的精鍊

本節將精鍊影片中提到的具體實作步驟，以幫助讀者快速掌握如何建立和部署一個 MCP 伺服器及相關工具。

技術棧清單：
* Python
* langchain-core
* openai
* fast-mcp (Model Context Protocol Python SDK)
* （可選）MPX model_context_protocol inspector (用於測試伺服器)
* 目標應用程式：Cursor, Windsurf, Claude Desktop (及其他支援 MCP 的應用)

實作流程：

1. 環境準備：

   • 在空的目錄中建立一個 Python 虛擬環境。
   • 安裝所需的 Python 套件，例如：pip install langchain-core openai fast-mcp。

2. 建立 LangGraph 查詢工具：

   • 載入文件： 使用 URL 載入器（如 LangChain 的 UrlLoader），從指定 URL（影片中為 LangGraph 文件的 URL）載入文件，並抓取多層子連結（例如深度至 5）。
   • 清理網頁： 應用一個提取器來清理載入的網頁內容。
   • 保存文件： 將所有載入並清理過的文件內容保存到一個文本檔案（例如 LMS_full.text）。
   • 分割文件： 將大型文本文件分割成較小的文件區塊（例如每塊 8,000 token），以適應嵌入模型的上下文限制。
   • 建立向量儲存庫： 使用嵌入模型（例如 OpenAI 嵌入）對分割後的文件進行嵌入，並建立一個向量儲存庫，將其保存到本地目錄。

   • 定義 LangChain 工具函數：
     ```python
     from langchain_core.tools import tool

     假設 vectorstore 已初始化並加載

     vectorstore = ...

     @tool
     def langgraph_query_tool(query: str) -> str:
     """
     Queries the LangGraph documentation vector store for relevant documents.
     """
     retrieved_docs = vectorstore.similarity_search(query)
     return "

".join([doc.page_content for doc in retrieved_docs])

* **將工具綁定到模型：** （此步驟展示 LangChain 內部機制，非 MCP 步驟）
python
# 假設 llm 已初始化
# llm = ...
augmented_llm = llm.bind_tools([langgraph_query_tool])
```

1. 建立 MCP 伺服器腳本 (langgraph_mcp.py)：

   • 導入 fast_mcp。
   • 創建 fast_mcp.Server 實例。
   • 使用 server.add_tool() 方法將之前定義的 langgraph_query_tool 添加到伺服器。

   • （可選）使用 server.add_resource() 方法添加文件資源，例如：
     ```python
     from fast_mcp import Server, Resource
     import os

     server = Server()
     server.add_tool(langgraph_query_tool)

     @server.add_resource(name="docs_langgraph_full")
     def langgraph_full_docs() -> str:
     with open("LMS_full.text", "r", encoding="utf-8") as f:
     return f.read()

     最後一行用於運行伺服器

     if name == "main":
     server.run() # 默認使用標準 I/O
     ```

   • 確保腳本以 server.run() 啟動，通常使用標準 I/O 模式。

2. 測試 MCP 伺服器：

   • 使用 MPX model_context_protocol inspector 工具來測試伺服器： bash MPX model_context_protocol inspector
   • 在 inspector 介面中，指定你的 Python 虛擬環境路徑和伺服器腳本的路徑。
   • 連接後，可以列出並查看已暴露的資源（如 docs_langgraph_full）和工具（如 langgraph_query_tool），並直接運行工具進行測試。

3. 配置主機應用程式：

   • 將一個小的配置程式碼片段添加到 Cursor、Windsurf 或 Claude Desktop 的配置檔案中。
   • 該片段應包含執行 MCP 伺服器腳本的命令（Python 解釋器路徑、腳本路徑）和任何必要的參數（例如 OpenAI API 金鑰，如果工具需要它來進行嵌入）。
   • Cursor 範例配置路徑： 通常在 Cursor 的設置中找到 MCP 配置選項。
   • Windsurf 範例配置路徑： 在聊天介面中，通常會顯示可用的 MCP 伺服器，點擊配置按鈕可導向相關檔案。
   • Claude Desktop 範例配置路徑： 在設置中進入開發者選項，即可編輯配置檔案。

完成這些步驟後，你的 MCP 伺服器將被主機應用程式自動發現、啟動並調用，從而將你自定義的工具和資源整合到 AI 應用體驗中。

第四部分：光之延伸 — 洞見拓展與自由發揮

模型上下文協議（MCP）的出現，不僅僅是技術層面的一項創新，它預示著 AI 代理與人類應用交互方式的深遠變革。長久以來，大型語言模型的能力雖強大，卻常受限於其封閉的知識邊界與有限的實體互動能力。當我們試圖將 LLM 從單純的文本生成器，提升為能動態獲取資訊、執行複雜任務的智慧代理時，一個標準化的「溝通橋樑」便成為必然。

MCP 正是這座橋樑。它將工具、資源乃至於提示詞，從 LLM 內部框架的約束中解放出來，使其能夠以統一的語言，與各式各樣的 AI 應用程式對話。這背後代表的，是 AI 生態系統從「各自為政」走向「互聯互通」的關鍵一步。想像一下，一個在本地定義的程式碼工具，能夠被你的 IDE、聊天機器人、甚至其他生產力工具無縫調用，這將極大提升開發者的效率和終端用戶的體驗。

從宏觀角度看，MCP 推動了「LLM 即應用協調者」的願景。LLM 不再是那個無所不知的「大腦」，而是能夠巧妙指揮各種專門工具的「指揮家」。這就像人類社會分工合作一樣，每個人專精於自己的領域，然後透過共通的語言與規範（MCP），共同完成複雜的專案。這不僅降低了構建多功能 AI 代理的門檻，也為未來更複雜、更智慧的 AI 系統奠定了基礎。例如，一個 AI 代理可能需要從網路獲取最新數據（工具 A），然後將數據存儲到本地知識庫（工具 B），接著根據數據生成報告（工具 C），並最終將報告發送到通訊平台（工具 D）。MCP 使這些跨應用、跨功能的流暢協調成為可能。

然而，MCP 的發展仍有其挑戰。影片中提到，目前並非所有主機應用程式都完全支援資源（如文件）的暴露，這限制了 LLM 獲取豐富上下文的潛力。此外，隨著更多工具和資源的整合，安全性、性能優化以及更完善的錯誤處理機制將成為協議演進的重點。如何確保不同來源的工具都能安全地執行，並且在大量調用時仍能保持低延遲，將是未來需要持續探索的方向。

這位演講者親身經歷的「從困惑到理解」的旅程，恰恰反映了新興技術推廣的普遍困境。許多強大概念往往被繁雜的細節所掩蓋，唯有透過清晰的拆解與實踐，才能真正揭示其核心價值。MCP 作為連接 LLM 與其外部世界的關鍵協議，其簡化與標準化將加速 AI 應用的普及與創新，使 AI 的能力真正融入我們日常的工作與生活之中。這不僅僅是技術的進步，更是人類與 AI 協同創作新篇章的序曲。