最近開始認真研究 MCP, 除了研究規格之外, 更重要的是研究怎樣使用才是他最初設計的用意。無奈現在 MCP 的支援還很混亂, 光用 “體驗” 的根本搞不清楚這是規格問題還是支援度問題… 正好看到今年 5 月 Anthropic 舉辦的 Code w / Claude 的這段影片 - MCP 201, 解除了我很多對 MCP 為何這樣設計的疑問, 還蠻值得看一下的, 大推
這場的講者, 是由 MCP 這團隊的成員直接出來介紹的 (這應該就是真的第一手資訊了吧), MCP 其實想做的不只是 “賦予 Agent 執行任務” 的能力而已 (過去我都一直這樣認為), 而是從未來人們如何跟 Agent 互動, 想像未來的軟體服務 ( SaaS 的未來? ) 該如何跟 Agent 互動, 而設計出來的協定。
上一篇我就聊過, 人們都怎麼跟 Agent 互動的? 有三種主要的方式:
- 問問題 ( prompts, 使用者觸發 )
- 上傳附檔 ( resources, 應用程式觸發 )
- 啟用工具支援 ( tools, 由 LLM 觸發 )
而未來的軟體服務，若要充分的配合人類跟 Agent 的互動而給予最好的支援, 自然就是推出服務時, 都能自己準備好這三件事了。MCP 開發人員, 理應是最清楚自身服務該如何使用最有效率, 因此由開發人員來寫 prompts, 由開發人員定義好需要那些 resources, 由開發人員準備好 tools, 打包成一套完整的 MCP server 給 Agent 使用，是未來最理想的服務發布的型態。
也因此這段 20 分鐘的場次, 一開始就提到 MCP 這三種基本操作。而為了讓這些互動更緊密整合，背後擴充了兩種進階的協定 ( 說真的我第一次看 MCP 規格就覺得名字取的很爛, 結果 speaker 自己也承認了 XDD )，除了 prompts, resources, tools 之外, 這兩個進階的協定分別是:
- Sampling ( 賦予 tools 使用 LLM 的能力 )
- Roots ( 對 tools 宣告使用範圍的機制 )
這兩個名詞爛到我不知道怎麼翻譯，就維持原文吧 XDD, Sampling 就是讓 MCP tools 能反過來用 MCP Host 的 LLM 的機制, 可以把需要 LLM 的資源都集中在 Application 本身 ( Application 本身通常都是訂閱制度, 不像 API 是照使用量, 大部分情境集中 Token 的 Usage 對費用都有幫助 )。而 Roots, 比較像是 “授權範圍” 的宣告, 實際做法我還沒研究, 但是影片中舉了一個案例我覺得還蠻清楚的，他說:
就好像你用 vscode 開啟了專案, 用 git mcp 要取得 issue 內容, 不過 mcp 怎麼知道你現在開哪個 repo ? 你該讀取那個 repo 下的 issue ? 這時就要靠 roots 協定, 讓 vscode 告訴 mcp 這件事, 就能做到這需求。 —-
到這裡為止，全部的協定內容串聯起來，我才發現，MCP 可能就是未來 SaaS 的發展路線啊! 現在的 SaaS 不論提供什麼 UI / APP 等，都會同時提供 API 來建立他的生態系，跟其他環境緊密整合。而未來，替代 API 的角色的東西就會是 MCP，整合的對象也會從其他 SaaS 變成 Agent. 而 MCP 不只是要用 tools 替換掉 API, 而是把整個跟 AI 的應用生態跟整合方式都考慮進去, 而制定出來的標準
影片最後一段也提到, 除了這些應用情境, 現今大部分 MCP server 都是部署在本地端, 未來也會持續往 remote 端轉移。除了通訊協定換掉 stdio 之外, 還有另外兩件事要解決:
- Authorization ( OAuth2.1 )
- Scaling ( 就是典型的 API scaling 機制 )
技術細節我就不多說了, 以後有機會在來聊實作題, 短短 20 分鐘的影片, 有系統的交代完這些設計脈絡, 我覺得還蠻有收穫的, 推薦大家有空可以看一下。影片跟我提到幾個相關連結我放留言
