Note: MCP（上）

前言

最近Google 發布A2A protocol 延伸了去年Anthropic 提出的MCP，在 dive in A2A 之前想來紀錄一下 MCP 筆記。

在研究MCP的時候，看了很多medium或YouTube等等的分享，在這裡想要提到實作及基本知識以外，更多值得討論的概念。

📌這篇文章希望能由淺入深，讓大家看到MCP除了只是「串一堆資料源或串API給代理人自動選用」的其他面向，同時也不那麼的枯燥乏味。

溫馨提醒：文章不小心寫太長，所以分成上下兩部分，可以跳到自己有興趣的地方🥸

What is the Model Context Protocol (MCP)?

MCP 的全名為Model Context Protocol ，是一個開放式協議，由Anthropic於2024年11月提出，可實現AI 應用程式與代理和你的工具與資料來源之間的無縫整合。

在日常生活中，可以想像MCP就像是AI application中的USB-C，USB-C為各種電子設備連接到電腦提供了統一的介面標準一樣，如封面所示（圖片來源：https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/）

在軟體領域的話，舉APIs 和 LSP 的概念和MCP 相比或許會更容易理解👇

ㅤ	API	LSP	MCP
概念	將web application 如何與backend 的互動標準化	將IDEs如何與Language server tools的互動標準化	將 AI applications 如何與外部系統的互動標準化
其中會參與的角色	servers, databases, services	code navigation, code analysis, code intelligence	prompts, tools, resources

What is the influence of MCP ?

看到這裡，如果你在思考MCP 標準化帶來什麼影響的話，就繼續看下去吧！

Without MCP: Fragmented AI Development

With MCP: Standardized AI Development

從以上兩張圖可以看出，在沒有MCP之下，開發一個AI 應用，我們往往需要許多元件的客製化才能完成。然而，有了MCP後在四種不同層面將得到大幅的增益

角色	影響
AI應用開發者或工程師	將既有的app 直觀地接上MCP server而不需要額外的工作
MCP server端或tool的開發者	開發後的MCP server 將會在任何地方都適用
終端使用者	MCP 能提供更豐富、強大的AI應用場景
企業端	AI 產品團隊之間的職責更明確

Building with MCP

接下來，以下將介紹幾個MCP中有關的角色

角色	控制方	描述	範例
MCP Host	-	想要透過 MCP 存取資料的應用程式	Claude Desktop、IDE、AI工具
MCP Client	-	與MCP server建立1對1連接，模型可自行判斷何時調用工具	-
MCP Server	-	向Client應用程式expose工具	CRM MCP Server
Tools	模型	由模型調用的功能，並提供使用方式說明	檢索/搜尋、發送訊息、更新資料庫記錄
Resources	應用程式	向應用程式開放的資料，提供豐富介面進行互動	檔案、資料庫記錄、API回應
Prompts	使用者	預先定義的AI互動模板，視為使用者調用的工具	文件問答、會議記錄摘要、JSON格式輸出

Resources vs Tools 的基本差異

設計面	控制權	優點
分開設計以優化model運作並豐富application與server互動	Tools由model控制，Resources由application控制	符合MCP規範的application可依需求決定何時放入resources (透過default rules或LLM call)

Vector Database 整合

主要考量use case需求，可以適用於以下情境：

不確定何時該invoke tool時

LLM需要在不同時機呼叫資料庫時

https://milvus.io/docs/zh-hant/milvus_and_mcp.md

MCP與Agent Framework的協作關係

🤝 互補性質：

MCP專注於提供標準連接

Agent Framework負責：

Knowledge management
Agent loop管理
Tool回傳data的處理

例如：LangGraph提供connector銜接agent到MCP

Resources & Prompts的靈活運用

核心特性：

Dynamic特質：可與user/application context互動

Customization：server可根據任務客製化content

即時性：resource notification功能支援即時updates

MCP的價值主張：

提供tool的standard invocation方式

為system components提供更多控制權

建立rich interaction的標準框架

Transports

Message Format

對於 Request、Response 及 Notification ，MCP都統一採用JSON-RPC 2.0作為訊息格式。

而訊息交換流程為：

初始化階段：

客戶端發送 initialize 請求，包含協議版本和功能。

伺服器回應其協議版本和功能。

客戶端發送 initialized 通知作為確認。

訊息交換階段：

雙方可交換請求和回應。

可發送通知進行單向通訊。

終止階段：

任一方可透過 close() 方法、傳輸中斷或錯誤條件終止連線。

Transport Type

MCP 支援Buit-in（Stdio/SSE）及Custom的傳輸形式

傳輸類型	描述	適用場景	特點
標準輸入/輸出（Stdio）	透過標準輸入（stdin）和標準輸出（stdout）進行客戶端與伺服器之間的通訊。	本地整合，例如命令列工具或 IDE 擴充功能。	低延遲，無需網路堆疊；簡單的進程間通訊；一對一的客戶端與伺服器關係。
伺服器推送事件（SSE）	使用 HTTP POST 請求進行客戶端到伺服器的通訊，並透過 SSE 通道將伺服器的事件推送給客戶端。	需要伺服器到客戶端的即時資料推送，例如 Web 應用。	支援伺服器到客戶端的即時資料流；適用於遠端伺服器與客戶端之間的通訊。
自訂傳輸機制	開發者可根據需求實作自訂的傳輸機制，只要符合 MCP 的傳輸介面規範。	需要特殊網路協定或通訊通道的應用，例如 WebSocket。	高度靈活，可根據需求設計傳輸方式；需要自行處理傳輸層的實作與安全性。

為什麼MCP 將成為代理系統的基礎協議？

隨著這些代理系統不斷進步，模型本身也在提升，並且能越來越有效地運用您提供給它們的數據

MCP賦予LLM的核心能力

允許LLM主動調用Tools並以智能方式回應這些工具的結果

讓LLM實際擁有某種狀態

例如：每次互動不會重新開始→能持續追蹤其進展

MCP作為底層架構

作為統一標準，使LLM能夠：

與檢索系統對話
調用各種Tools
引入記憶功能

主要特點：無需預先建立所有功能，代理可在運行過程中發現並使用新功能

代理系統的簡單本質

代理系統的核心其實並不複雜。它們是一個增強型LLM的概念，在循環中運行，增強型LLM執行任務，朝向某個目標努力，調用工具，查看回應，然後重複這個過程直到完成任務。

MCP對開發者的價值

開發彈性	使用者自主性	開發重點
即使開發時不知道代理需要做的所有事情也沒關係	代理可讓使用者自訂上下文和數據處理方式	開發者可專注於核心循環、上下文管理、記憶使用和模型選擇

MCP的抽象優勢

MCP作為一個抽象層，讓代理開發者能真正專注於具體任務，以及代理應該如何與周圍系統互動，而不是必須關注實際的server本身、tools或resources。

MCP常見問題

在探討代理系統與MCP的整合時，經常會遇到一些關於資料安全和系統架構的疑問。讓我們來了解兩個最常見的問題。

首先，許多人關心代理系統是否能安全地處理專有數據。這個問題的答案是肯定的。由於MCP是開源協議，組織可以在自己的VPC（虛擬私有雲）環境中運行MCP伺服器，確保數據的安全性和隱私性。

另一個重要問題是關於代理系統的模組化設計。當我們談到「將代理本身與其他功能分開」時，實際上是在討論一種靈活的系統架構。這種設計允許開發者根據具體需求，建立一系列高度客製化的MCP伺服器。更重要的是，當需要與外部系統整合時，MCP的標準化協議使得這個過程變得簡單直接，因為所有必要的連接接口都已經預先定義好了。這大大減少了系統整合的複雜度，讓開發者能夠專注於實現核心功能。

參考資源

結語

除了簡介MCP，這篇文章也談到很多MCP有關的優勢及問題

下集 Note: MCP（下）將談到更多有關MCP Agent、Sampling、Composability、Registry以及未來發展等等，希望這個筆記有幫助到你！

如果有任何問題，都歡迎聯繫我的IG部落格帳號 davidtechtalks 我們下次見！