Note: MCP（下）

前言

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

如果還不了解MCP的話，可以參考 Note: MCP（上）

📌 這篇文章將談到更多MCP Agent、Sampling、Composability、Registry以及未來發展。

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

MCP Agent以及系統架構

MCP Agent是一個強大的框架，提供以下核心功能：

簡單的上下文注入機制

使用 declarative frameworks 實現各種工作流程

提供多樣化的代理建構元件

以LastMile AI 的MCP Agent 為例，它提供一個簡單的框架，利用MCP去實作Agent🤖

https://github.com/lastmile-ai/mcp-agent

系統架構設計考量

元件	責任分配
Client 端	- 無需了解重試邏輯- 不需知道日誌細節
Server 端	- 較接近最終應用程式- 擁有更多系統互動控制權

可擴展性與限制

目前模型處理能力：

一般模型（如Claude）：50-100個工具

進階模型：數百個工具

工具管理策略

為了有效管理大量工具，或許可以採用以下方法：

工具搜尋系統

實現RAG的工具抽象層
基於工具庫的模糊搜尋

階層式系統結構

例如：金融工具集、資料讀取工具集、資料寫入工具集

實作指南

建構MCP伺服器的建議步驟：

從基礎工具開始理解MCP Server架構 → 進入Prompt設計 →配置Resource管理

自動化與整合

值得注意的是，MCP支援自動化MCP server生成：

透過如Cline等工具

支援即時MCP Server生成功能

維護與更新考量

系統變更管理原則：

遵循MCP協議確保基本功能

工具可動態更新與演進

保持資源提示詞一致性

維持標準化工具調用方式

Building Effective Agents with MCP

接下來會介紹MCP中重要的兩個概念，Sampling 及 Composability

Sampling

在 MCP 中，Sampling 是一項強大的功能，允許伺服器透過客戶端請求大型語言模型（LLM）生成回應（即「completion」或「generation」）。這使得伺服器能夠在執行工具、提示或工作流程時，根據上下文動態地請求模型生成內容，同時保持安全性和隱私性。

🤔 為何使用 Sampling？

傳統上，伺服器若需使用 LLM，必須自行管理 API 金鑰、模型選擇和成本控制。而 MCP 的 Sampling 功能改變了這一點：

伺服器無需直接訪問 LLM：伺服器可以透過客戶端請求 LLM 的推理結果，無需自行託管或直接訪問模型。

用戶保持控制權：客戶端可以審查和修改伺服器的請求，確保符合用戶的隱私和安全需求。

靈活的模型選擇：客戶端可以根據伺服器的偏好和自身的可用模型，選擇最合適的模型進行推理。

🔁 Sampling 的工作流程

伺服器發送請求：伺服器透過 sampling/createMessage 方法向客戶端發送請求，包含對話歷史、系統提示、模型偏好等資訊。

客戶端審查請求：客戶端審查並可修改該請求，確保符合使用者的控制和隱私需求。

執行 LLM 推理：客戶端根據請求內容，選擇適當的模型進行推理。

審查生成結果：客戶端審查 LLM 的生成結果，確保其符合預期。

返回結果給伺服器：客戶端將生成的結果返回給伺服器，供後續處理或回應使用者。

這種設計確保了使用者對模型輸入和輸出的控制，並允許在多步驟的代理行為中嵌套 LLM 呼叫。

請求格式

Sampling 請求使用標準化的訊息格式，包含以下欄位：

messages：包含對話歷史的陣列，每個訊息包含角色（user 或 assistant）和內容（文字或圖片）。

modelPreferences：模型選擇偏好，包括模型名稱提示（hints）、成本優先度（costPriority）、速度優先度（speedPriority）、智能優先度（intelligencePriority）。

systemPrompt：可選的系統提示詞，用於引導模型行為。

includeContext：指定包含的上下文範圍，可選值為 none、thisServer 或 allServers。

temperature：控制生成內容的隨機性，範圍為 0.0 至 1.0。

maxTokens：生成內容的最大 token 數量。

stopSequences：可選的停止序列，當模型生成到這些序列時停止。

metadata：可選的額外參數，用於提供特定模型提供者的需求。

官方的example request：


{
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "What files are in the current directory?"
        }
      }
    ],
    "systemPrompt": "You are a helpful file system assistant.",
    "includeContext": "thisServer",
    "maxTokens": 100
  }
}

🔐 安全性與用戶控制

Sampling 的設計強調「人類在環中」（human-in-the-loop）的理念，確保用戶對模型的輸入和輸出保持控制。客戶端可以：

審查和修改伺服器的請求內容，防止潛在的惡意或不當請求。

限制模型的使用，例如設置每日使用次數上限或限制特定模型的使用。

審查模型的生成結果，確保其符合用戶的期望和安全標準。

以上措施確保了在多代理系統中，客戶端仍然保持對模型互動的最終控制權！

→ 通過讓客戶端掌控所有與LLM的互動，這使得這些請求可以聯合處理，如果是開源的話，客戶端還可以自行託管LLM。他們可以決定實際使用什麼類型的模型

例如：伺服器可以使用各種不同參數請求推理，比如模型偏好設定，也許伺服器會說「我特別想要這個版本的Claude，或者我想要一個大模型或小模型，請盡可能滿足這些要求」，伺服器當然會向客戶端傳遞系統提示詞和任務提示詞，以及它可以請求的溫度、最大字符數等參數。客戶端不必遵從這些要求。客戶端可以說「這看起來像是惡意調用，我不會執行」，而且客戶端對隱私和成本參數等方面有完全的控制權，可能會限制伺服器的請求次數

2. Composability（可組合性）

在這前面有提到Client 跟 Servere會分離。但是，Client 和 Server 其是邏輯上的分離，而非實體的分離！

也就是說 → 任何應用程式、API或代理都可以同時作為MCP Client 和MCP Server

MCP代理系統概述

在MCP架構中，代理可以同時扮演客戶端和伺服器的角色。以下是一個實際的使用場景：當使用者與Claude Desktop (LLM) 對話時，可以請求研究代理協助搜尋資訊。這個研究代理具有雙重身份：既是MCP伺服器也是MCP客戶端。它可以調用多個資源，如檔案系統、資料擷取和網路搜尋等服務，處理所得資料後回傳結果。

代理鏈結架構

這種系統建立了一個鏈結式架構：使用者 → 客戶端/伺服器組合A → 客戶端/伺服器組合B，依此類推。這讓我們能建立多層次的LLM系統，每個層級專注於特定任務。

可能的問題與解答

問題類別	問題	解決方案
錯誤處理	如何處理多層次系統中的累積錯誤？	這是通用的多節點挑戰，取決於每層代理如何處理資訊流。MCP本身不會使這個問題更容易或更困難。
protocol選擇	為何需要MCP而非HTTP？	MCP提供更豐富的功能：資源通知、雙向通訊、資料請求等。支援複雜的非同步多步驟互動。
智能代理	為何要將普通服務轉換為MCP？	賦予服務代理特性，使其具備自主決策能力，能更智慧地處理任務和互動。

系統控制與觀察性

LLM位於應用層，可控制速率限制和互動流程

系統運作類似黑盒子，伺服器可自主決定調用其他服務，而可觀察性取決於建立者和生態系統設計。

除錯與安全性

使用inspector工具進行日誌查看和連接監控支援伺服器除錯功能授權和認證由伺服器建立者控制提供工具註解功能，支援讀寫權限控制

3. Sampling + Composability

除此之外，也可以將Sampling和Composability合併 → 將多個代理串接起來，同時確保由Client 端應用程式掌控推理過程（如下圖）。

有時候這些代理（agents）會存在於公開網路上，或者它們不是你親自建構的。但你仍然可以透過 MCP 的方式與它們連接，同時保有你在建構這些系統時所希望具備的隱私性、安全性與控制權。

那我可不可以用RESTful API 做就好了？讓我們來看看兩者的比較吧

MCP 和 RESTful API 的差異是什麼？它們之間會有互動嗎？

MCP vs. RESTful API	MCP	RESTful API
設計目的	控制 LLM 推理與工具互動的流程，加入邏輯與上下文處理	用於客戶端與伺服器間進行資料的 CRUD 傳遞
資料處理能力	支援複雜的資料轉換、上下文組合與模型提示邏輯	傳遞結構化資料為主，資料格式固定
互動性	支援有邏輯導向的多輪對話或複雜工具鏈整合	適合單次、無狀態的請求-回應模型
與 LLM 的整合程度	高，適合處理「你應該注意這五件事」這類多步邏輯，伺服器可控制推理細節	低，一般僅用於傳輸模型輸入與輸出，不處理推理邏輯
應用場景	多代理系統、智慧助手、需要語境理解與邏輯運算的複雜應用	簡單 API 接口、CRUD 資料操作、無狀態後端服務
狀態管理	可維持上下文與流程邏輯，有助於打造有記憶的 agent 互動	無狀態設計，每次請求皆為獨立事件

What’s next for MCP

隨著 MCP 被越來越多代理應用與語言模型生態採用，開發者社群也面臨新的需求與挑戰。為了讓 MCP 生態更具可擴展性與穩定性，官方團隊正在推進幾項關鍵建設——包括遠端伺服器支援、正式身份驗證機制、以及最重要的 MCP Registry API。

遠端MCP Server 與身份驗證支援

MCP 的部署方式不再限於本地進程（Stdio），許多開發者與企業希望能將 MCP Server 安裝在雲端或公司內網，支援跨網域或跨系統的整合。

Remote MCP Servers + Auth

Inspector 工具已正式支援 身份驗證（auth）

推薦的遠端傳輸方式為 SSE（Server-Sent Events），其可實現低延遲且穩定的雙向即時推送

官方MCP Registry API（開發中）

為何需要 Registry？

目前 MCP server 分散在 GitHub、npm、PyPI、Rust 等生態，造成：

難以發現與安裝

傳輸協定不透明

無版本追蹤與信任來源

MCP Registry API 是什麼？

官方 MCP 團隊正在建構一個 開放但統一托管的 Registry API，這個平台將解決上述所有碎片化問題，提供：

功能	說明
中央託管	由官方 MCP 團隊維運，但 schema 和開發皆開源進行
生態整合	可整合到 npm、PyPI、Cargo、Go Modules 等現有套件系統
Metadata 查詢支援	每個 MCP server 的協定、傳輸方式、建置者、版本歷史皆可查詢
版本控制與差異追蹤	支援註記：哪些工具被新增？哪些描述被更新？API 有無變動？皆可比對版本差異

舉例：

Shopify 想發佈官方的 MCP server。透過 Registry API，開發者可以確認該 server 是否經過 Shopify 驗證，支援哪種傳輸、是否需身份驗證、提供哪些工具等等資訊。

常見問題

主題	問題描述	答案摘要
是否支援自建 Registry	企業是否能架設自己的 MCP registry？	✅ 支援。除了公有 registry 外，也能自架私有 registry，並與 VSCode、Cursor 等開發環境整合。UI 不受限制，僅提供介接資料。
是否開源/開放	MCP 是開源還是封閉？是否支援其他模型供應商？	✅ 完全開放。MCP 是開放協定，Claude 並非唯一 client，其他 LLM 廠商也可參與實作。競爭是健康的，對使用者與開發者有益。
Server 是否可主動觸發互動	MCP 支援伺服器主動啟動推理或與 client 發起互動嗎？	✅ 部分支援，目前可通知資源更新。主動 sampling 尚未支援，但已規劃中。伺服器也可作為 client 搭配自有 LLM，實現進階互動與組合邏輯。
模型是否必須在互動中參與	MCP 互動是否必需模型參與才能操作？	❌ 不一定。client 可直接調用工具或資源，不必每次都透過模型參與，支援 deterministic 控制流程。
是否支援 server-to-server	MCP 允許伺服器與伺服器直接溝通嗎？	✅ 有彈性但非預設。預設需透過 client 控制互動，確保安全與層次分離。但架構允許自行實作 server 間溝通流程。

MCP Registry：讓 AI 代理具備自我進化能力🦾

MCP Registry 將徹底改變代理的設計模式，讓代理不再依賴預先定義工具，而能動態發現、載入並使用新的能力。

代理如何「自我進化」？

傳統代理必須事先知道有哪些工具可用，而 MCP Registry 讓代理在運行時能：

搜尋 Registry 找到所需工具（例如 Google Map server）

驗證來源可信後透過 SSE 等方式連接

動態使用該工具完成任務（如定位、計算距離、路線等等）

✅ 不需預打包、不需人工配置，代理能根據任務「自己變強🦾」。

🔐 如何控管安全與存取？

MCP 團隊提出類似企業 DevOps 的解法：

控制方式	說明
自架 Registry	控制哪些 MCP server 可供代理使用
白名單查詢	限制代理只能從特定清單中尋找與存取工具
官方驗證標章	讓代理能判斷 server 是否為 Shopify、Grafana 等可信來源
中介過濾器	加一層工具過濾機制，阻擋未授權 server 存取

小結

傳統代理設計	MCP 新模式
工具寫死、難擴充	可動態搜尋、載入、使用外部工具
需人工整合與部署	代理自動完成工具搜尋與連接
無驗證與權限控管	Registry 提供驗證、白名單、安全過濾支援

→ MCP Registry 將讓代理從「被動工具使用者」變成「主動智慧決策者」。

Beyond Registry：讓代理智慧整合 `.well-known` 與 MCP 架構的未來

隨著 MCP 推動 AI 代理邁向更動態、可組合的工具整合生態，我們正迎來另一個關鍵補充機制：.well-known/mcp.json。它不僅補足 MCP Registry 的限制，更為未來的智慧代理鋪設了可理解、可存取的網路結構。

`.well-known/mcp.json` 是什麼？

.well-known 是一種在網站根目錄中公開標準資訊的通用方式（如 .well-known/robots.txt, .well-known/openid-configuration 等）。對於 MCP 而言，它代表網站主動公開自己的 MCP 端點與工具清單。

舉例說明：

假設 Shopify 提供 https://shopify.com/.well-known/mcp.json，內容可能包含：


{
  "mcp_endpoint": "https://api.shopify.com/mcp",
  "tools": ["order.read", "product.update"],
  "auth": {
    "type": "oauth2",
    "token_url": "https://shopify.com/oauth/token"
  }
}

這表示如果使用者告訴代理：「幫我管理我的 Shopify 商店」，代理就能直接查詢這個 .json 檔，取得所有對接所需資訊——不需要事先知道這些工具、API、認證方式。

Registry 與 `.well-known` 的角色差異

功能層面	MCP Registry	`.well-known/mcp.json`
發現方式	從一個中央平台「搜尋並探索」不特定伺服器	針對已知網站，主動查詢其是否支援 MCP
適用情境	不知道有哪些工具可用、從零開始尋找	已知道某個網站（如 shopify.com），想直接整合
探索視角	bottom-up（從零發現工具）	top-down（網站主動提供入口）
互補關係	全局工具索引與驗證平台	單一網站的介面暴露與整合指引

兩者互補，協助代理「從零找工具」，也能「對特定網站快速接入」。

搭配 Computer Use Model：打造全能型代理

Anthropic 在 2024 年 10 月推出的「Computer Use Model」讓代理可以像人一樣：

在沒有 API 的系統上點選 UI

自動登入、點擊按鈕、切換頁面

操作從未見過的介面

因此，我們可以想像這樣的代理系統：

若網站有提供 .well-known/mcp.json，代理就走 API 整合流程（快速、穩定、安全）

若沒有，代理就切換成 UI 操作模式（Computer Use），模擬人類操作完成任務

整合 MCP 與 Computer Use 的雙模式代理，或許是是Long-tail網站整合的未來解法。

小結：讓代理懂得查 `.well-known`，是 AI 邁向 Web 原生智慧的下一步

.well-known/mcp.json 是網站對代理「自我介紹」的方式

它補足了 MCP Registry 的 Discovery 層，讓代理支援「主動探索」與「被動註冊」

搭配 Computer Use，代理將能處理：

有 API → 快速調用
無 API → 模擬操作

如此一來，代理不再只是內建工具包，而是真正能「上網找工具」並「主動對接」的智慧體。

參考資源

結語

這篇關於MCP的文章很長，但其實還有很多值得挖掘的地方。希望透過這個筆記有幫助到你！

由於這是我第一次寫文章，才發現真的很不容易，不論是時間花費或是腦力，還要確保資訊的合理性。

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