MCP 創造者聊 MCP 的起源、架構優勢和未來

作者：FounderPark

Anthropic 在去年發布的 MCP 協議，今年因為 Manus 和 Agent 的熱潮，突然成為了 AI 領域最熱門的協議。 OpenAI、微軟、Google 等大廠也紛紛支持協議，國內阿里雲百煉、騰訊雲也迅速跟進，上線了快速搭建平台。

但爭議也不少，很多人質疑 MCP 和 API 區別不大、Anthropic 的工程師對互聯網協議不怎麼精通、以及協議太簡單帶來的安全問題等等。

讓 MCP 協議的發明者來回答這些問題，再合適不過了。

在 Latent Space 最近的一起播客中，他們邀請到了 Anthropic 團隊 MCP 協議的發明者——Justin Spahr-Summers、 David Soria Parra，詳細聊了聊 MCP 的起源，以及他們對於 MCP 諸多想法：為何推出 MCP、 MCP 與現有的 API 有何不同、如何讓 MCP 更好利用好工具等等。 信息量很大，建議收藏閱讀。

• Alessio Fanelli（主持人）：Decibel 合夥人兼 CTO

• swyx（主持人）：Small AI 創始人

• David Soria Parra：Anthropic 工程師

• Justin Spahr-Summers：Anthropic 工程師

• MCP 概念的「靈光一閃」來自 Anthropic 的一個內部項目 LSP（Language Server Protocol），兩位工程師藉由 LSP 的啟發，想到能否做一個類似 LSP 的東西，從而把「AI 應用與擴展之間的通信」標準化。

• MCP 的核心設計原則是：工具這個概念實際上不僅僅是工具本身，還與客戶端應用程序息息相關，進而也與用戶緊密相連。 通過 MCP 的操作，用戶應該擁有完全的控制權。 工具由模型控制，指的是僅僅由模型來調用，而不是由用戶主動指定使用某個工具（出於提示目的的情況除外）。

• 開放 API 和 MCP 並非相互對立，而是非常互補。 關鍵在於選擇最適合特定任務的工具。 如果目標是實現 AI 應用之間豐富的交互，MCP 更適合；如果希望模型能夠輕鬆讀取和解釋 API 規範，開放 API 會是更好的選擇。

• 對於 MCP 服務器的快速構建，利用 AI 輔助編碼是一種非常好的方式。 在開發初期，將 MCP SDK 的代碼片段放入 LLM 的上下文窗口，讓 LLM 幫助構建服務器，結果往往很不錯，細節可以在後期進一步優化，這是一種快速實現基本功能並進行迭代的好方法。 同時，Anthropic 的 MCP 團隊非常注重簡化服務器的構建流程，便於 LLM 能夠參與進來。

• AI 應用、生態系統和 Agent 的未來發展方向會傾向於 Statefulness，同時這也是 Anthropic 的 MCP 核心團隊內部最具爭議的話題之一。 在經過了多次討論和迭代後，得出的結論是儘管目前看好 Statefulness 的未來，但不能因此背離現有的範式，必須在 Statefulness 的理念和實際操作的複雜性之間找到平衡。

進群之後，你有機會得到：

• 高濃度的主流模型（如 DeepSeek 等）開發交流；

• 資源對接，與 API、雲廠商、模型廠商直接交流反饋的機會；

• 好用、有趣的產品/案例，Founder Park 會主動做宣傳。

01 MCP 是如何誕生的？

模型上下文協議，Model Context Protocol，簡稱 MCP，基本上是我們設計出來幫助 AI 應用拓展自身或集成插件生態系統的設計，具體而言，MCP 提供了一套通信協議，讓 AI 應用（我們叫「客戶端」）和各種外部擴展（我們叫「MCP 服務器」）能彼此協作。 這裡的「擴展」可以是插件、工具或者其它資源。

MCP 的目的就在於讓大家在構建 AI 應用時，能夠輕鬆引入外部服務、功能，或者調取更多數據，讓應用擁有更豐富的能力。 我們的命名中有「client-server」的概念，主要是為了強調交互模式，但本質就是在做一個「讓 AI 應用更易擴展」的通用接口。

不過需要強調的是，MCP 關注 AI 應用而非模型本身，這是常見的誤解。 此外，我們認同將 MCP 類比為 AI 應用程序的 USB-C 接口，它是連接整個生態系統的通用接口。

：實際上，大多就是我們倆在房間裡靈光一現想出來的。 這不是宏大戰略的一部分。 2024 年 7 月，我加入 Anthropic 不久，主要負責內部開發者工具。 期間，我思考如何讓更多員工深入整合現有模型，畢竟這些模型很棒，而且前景更好，自然是希望大家多用自家模型。

在工作中，基於我在開發工具方面的背景，很快就覺得有點沮喪，一方面因為 Claude Desktop 功能有限，無法拓展，而 IDE 又缺少 Claude Desktop 的實用功能，所以我只能在兩者間來回複製內容很麻煩。 久而久之。 我意識到這是個 MxN 的問題，也就是多個應用程序與多種集成的難題，而用一種協議解決再合適不過。 當時我還在做一個與 LSP（Language Server Protocol）相關的內部項目，沒什麼進展。 綜合這些想法，琢磨幾週後，我有了構建某種協議的念頭：

於是，我找到 Justin，分享了這個想法，幸運的是他很感興趣，我們便一起著手構建。

從有想法開始，花了約一個半月構建協議並完成首次集成。 Justin 在 Claude Desktop 首次集成中承擔了大量工作，我則在 IDE 中做了許多概念驗證，展示協議在 IDE 中的應用。 在正式發布前，查看相關代碼庫能發現不少細節，這就是 MCP 大概的起源故事 。

7 月左右，David 提出想法後，我很快就興奮地與他著手構建 MCP。 最初幾個月，因為搭建包含客戶端、服務器和 SDK 的通信協議有大量基礎工作，所以進展很緩慢。 但當東西能通過協議通信後，便令人興奮起來，能構建各種奇妙的應用。

後來我們內部辦了一場黑客松，一些同事用 MCP 編了可以控制 3D 打印機的服務器，還有實現「記憶功能」之類的擴展。 這些原型大受歡迎，讓我們相信這個想法能帶來很大潛力。

我們從 LSP 獲得很多靈感。 David 在開發工具方面對 LSP 經驗豐富，我主要從事產品或基礎設施工作，LSP 對我來說是新事物。

從設計原則看，LSP 解決了 David 提到的 M x N Problem。 之前，不同 IDE、編輯器和編程語言各自為政，你無法在 Vim 中使用 JetBrains 出色的 Java 支持，也無法在 JetBrains 中使用 Vim 出色的 C 語言支持。 LSP 通過創建通用語言讓各方能 「交流」，LSP 統一了協議，讓「編輯器-語言」各自只需要實現一次。 而我們的目標類似，只不過場景換成了「AI 應用-擴展」之間的對接。

具體細節上，我們採用 JSON-RPC 和雙向通信概念之後，走向了不同方向。 LSP 注重功能呈現，思考並提供不同的基本元素，而非語義的原則，我們也應用到 MCP 中。 之後，我們花大量時間思考 MCP 中的每個基本元素及其差異的原因，這是大量的設計工作。 一開始，我們想支持 TypeScript、PYTHon 以及用於 Zed 集成的 Rust 三種語言，構建含客戶端和服務器的 SDK，打造內部試驗生態系統，並讓本地 MCP 概念（涉及啟動子進程等）穩定下來。

我們參考了針對 LSP 的諸多批評意見，盡量在 MCP 中改進。 例如 LSP 在 JSON-RPC 上的某些做法太複雜，我們就做了一些更直接的實現方式。 因為構建 MCP 時，我們，比如選擇 JSON-RPC 之類的並不重要，而將重點放在基本元素等創新上，這些方面借鑒前人成果對我們很有幫助 。

某種程度上確實如此。 這是個很好的例子。 我在版本控制系統等方面處理過很多這類問題。 就是把問題都整合到一個大家能讀寫的東西里，構建「萬能盒子」來解決。 在開發者工具領域，這類問題隨處可見。

有趣的是，構建「萬能盒子」的人都會面臨同樣問題，也就是可組合性、遠程與本地問題等。 Justin 提到的功能呈現問題，有些本質相同的東西，卻要明確概念讓它的呈現方式不同。

02 MCP 的核心概念：工具、資源與提示缺一不可

我們從應用開發者角度思考每個基本概念。 開發應用時，不管是 IDE、Claude Desktop 或 Agent 界面，從用戶的角度想要從集成中獲取的功能，就會清晰很多，同時，工具調用是必要的，還要區分不同功能。

所以，MCP 最初的核心基本概念，後來又有所增加：

• 工具（Tool）：是核心。 即直接給模型添加工具，讓模型自行決定什麼時候調用。 對應用開發者而言，這類似「函數調用」，只是由模型發起的。

• 資源（Resource）：基本上指可添加到模型上下文的數據或背景信息，可由應用程序控制。 例如：可能希望模型自動搜索並找到相關資源，進而將它們納入上下文；也可能希望在應用程序中設置一個明確的用戶界面功能，讓用戶通過下拉菜單、回形針式菜單等方式，使其成為發送給 LLM 信息的一部分，這些都是資源的應用場景。

• 提示（Prompt）：特意設計為由用戶發起或由用戶替換的文本或消息。 打個比方，如果處於編輯器環境中，就如同斜杠命令，或者類似自動補全功能，比如有一個宏想要直接插入使用。

通過 MCP，我們對這些內容的不同呈現方式有自己的見解，但最終還是由應用開發者來決定。 作為應用開發者，能得到這些以不同方式表達的概念很有用，可以根據這些確定合適的體驗方式，形成差異化。 從應用開發者的角度考慮，他們不想讓應用千篇一律，在連接開放集成生態系統時，需要獨特做法來創造最佳體驗。

我覺得有兩個方面：第一個方面是，目前工具調用在集成中佔比超 95%，我期望更多客戶端運用資源調用、提示調用。 第一個實現的是提示功能，很實用，能構建可回溯的 MCP 服務器，這是用戶驅動的交互，由用戶決定信息導入時機，優於等待模型處理。 同時希望更多 MCP 服務器用提示展示工具用法。

另一方面就是資源部分也很有潛力，設想一個 MCP 服務器公開文檔、數據庫等資源，客戶端圍繞這些構建一個完整的索引。 因為資源內容豐富，不是由模型驅動公開，因為你可能擁有比在上下文窗口中實際可用的多得多的資源內容。 期待未來幾個月，應用程序能更好利用這些基本概念，打造更豐富的體驗。

我們區分工具與資源的方式是：工具由模型發起調用，由模型自行判斷找到合適的工具並應用，如果想讓 LLM 能運行 SQL 查詢，把它設為工具合理。

資源使用更靈活，不過目前因為很多客戶端不支持，情況很複雜。 理想狀態下，對於數據庫表架構等內容，可以通過資源調用。 用戶能藉這個告知應用相關信息開啟對話，或者讓 AI 應用自動查找資源。 只要有列出實體並讀取的需求，把它建模為資源就合理。 資源通過 URI 唯一標識，可視為通用轉換器，例如用 MCP 服務器解讀用戶輸入的 URI。 以 Zed 編輯器為例，它有一個提示庫和 MCP 服務器交互填充提示，雙方需就 URI 及數據格式達成一致，這是資源應用的很酷的交叉示例。

再回到應用開發者的角度，思考需求，把這種思路應用到實際中，比如，看看現有的應用功能，如果採用這種方式，哪些功能可以分離出來，由 MCP 服務器實現。 基本上，任何有附件菜單的 IDE，自然都可以建模為資源。 只是這些實現方式已經存在。

你願意為此提交一個 PR（Pull Request）嗎？ 我們非常喜歡這個建議。

好的，我去提交。

作為一名開發者關係人員，我一直致力於為人們提供清晰的指引，比如先列出關鍵要點，然後再花兩小時進行詳細講解。 所以，用一張圖來涵蓋核心內容非常有幫助。 我很欣賞你們對提示（Prompt）的重視。 在 ChatGPT 和 Claude 發展的早期，很多人嘗試創建類似 GitHub 上的提示庫、提示管理器庫，但最終都沒有真正流行起來。

確實，在這個領域需要更多的創新。 人們期望提示具有動態性，而你們提供了這種可能性。 我非常認可你們提到的多步驟提示（multi-step prompt）概念，這說明有時為了讓模型正常運行，需要採取多步驟的提示方式或是突破一些限制。 提示不僅僅是單次的對話輸入，有時它是一連串的對話過程。

是的，我認為這是一個合理的擔憂。 歸根結底，這是 MCP 的一個核心設計原則，即工具這個概念實際上不僅僅是工具本身，它與客戶端應用程序息息相關，進而也與用戶緊密相連。 通過 MCP 的操作，用戶應該擁有完全的控制權。 我們說（當然，出於提示目的的情況除外，但這不應該作為常規的用戶界面功能）。

但我認為，客戶端應用程序或用戶決定對 MCP 服務器提供的內容進行篩选和優化是完全合理的，例如客戶端應用可以從 MCP 服務器獲取工具描述並進行優化展示。 在 MCP 的範式下，客戶端應用應該擁有完全的控制權。 此外，我們還有一個初步的想法：在協議中添加功能，允許服務器開發者對提示、資源和工具這些基本元素進行邏輯分組。 這些分組可以被視為不同的 MCP 服務器，然後由用戶根據自己的需求將它們組合起來使用。

03 MCP 與 OpenAPI：競爭還是互補？

從根本上講，開放 API 規範是一個非常強大的工具，我在開發 API 及其客戶端時經常使用。 但是，對於大型語言模型（LLM）的應用場景而言，開放 API 規範顯得過於細化，它沒有充分體現更高級別的、針對 AI 的特定概念，比如我們剛才提到的 MCP 基本概念以及應用開發者的思維模式。 與僅僅提供一個 REST API 讓模型去自由發揮相比，模型能夠從專門為其設計的工具、資源、提示以及其他基本概念中獲得更多益處。

另一方面，在設計 MCP 協議時，我們刻意使其具有一定的狀態性。 這是因為 AI 應用和交互在本質上更傾向於 Statefulness（有狀態）。 儘管 Stateless（無狀態） 在一定程度上始終有其用武之地，但隨著交互模式（如視頻、音頻等）的不斷增加，Statefulness 會變得越來越受歡迎，因此，Statefulness 的協議也顯得尤為有用。

實際上，開放 API 和 MCP 並非相互對立，而是相輔相成的。 它們各有強大之處，而且非常互補。 我認為關鍵在於選擇最適合特定任務的工具。 如果；如果希望模型能夠輕鬆讀取和解釋 API 規範，那麼開放 API 會是更好的選擇。 早期已經有人在這兩者之間搭建了橋樑，有一些工具可以將開放 API 規範轉換為 MCP 形式進行發布，反之亦然，這很棒。

我認為這兩種情況都會存在。儘管目前更多的是默認使用工具調用，但未來其他的基本概念或許更適合解決這類問題。 即使它仍然是一個連接器或適配器層，通過適配不同的概念也能增加其價值。

例如，一個內存 MCP 服務器可以讓 LLM 在不同的對話中記住信息；一個順序思維 MCP 服務器可以提升模型的推理能力。 這些服務器並非與外部系統集成，而是為模型提供全新的思考方式。

無論如何，利用 AI 來構建服務器是完全可行的。 即使需要實現的功能並非適配其他 API，而是具有原創性，模型通常也能找到實現的途徑。 確實，很多 MCP 服務器將會是 API 封裝器，這既合理又有效，能幫助你取得很大進展。 但我們目前仍處於探索階段，還在不斷探索能夠實現的可能性。

隨著客戶端對這些基本概念支持的不斷完善，將會湧現出豐富的體驗。 例如，一個能夠「總結 Reddit 版塊內容」的 MCP 服務器，目前還沒有人構建，但協議本身完全能夠實現。 我認為，當人們的需求從「我只是想把我關心的事物連接到 LLM 上」轉變為「我想要一個真正的工作流程，一個真正更豐富、我希望模型能夠深入互動的體驗」時，你就會看到這些創新應用應運而生。 不過，目前在客戶端支持的能力與服務器開發者想要實現的功能之間，確實存在著一個「先有雞還是先有蛋」的問題。

04 怎麼快速構建 MCP 服務器：用 AI 編程

我有一些建議。 MCP 的一個優點在於，構建一些簡單的功能非常容易，大約半小時就能搭建好，雖然可能不完美，但足以滿足基本需求。 最好的入門方法是：選擇你喜歡的編程語言，如果有相應的 SDK 就直接使用；構建一個你希望模型能與之交互的工具；搭建 MCP 服務器；將這個工具添加到服務器中；簡單地編寫一下工具的描述；通過標準輸入輸出協議將其連接到你喜歡的應用程序；然後觀察模型能夠如何使用它。

對於開發者來說，能夠快速看到模型作用於他們所關注的事物上，這一點非常有吸引力，能夠激發他們的熱情，進而促使他們深入思考還需要哪些工具、資源和提示，以及如何評估效果並優化提示。 這是一個可以不斷深入探索的過程，但首先從簡單的事情入手，看看模型如何與你關心的內容進行交互，這本身就充滿了樂趣。 MCP 為開發增添了趣味性，能夠讓模型快速發揮作用。

我還傾向於。 在開發初期，我們就發現可以將 MCP SDK 的代碼片段放入 LLM 的上下文窗口，讓 LLM 幫助構建服務器，結果往往很不錯，細節可以在後期進一步優化。 這是一種快速實現基本功能並進行迭代的好方法。 從一開始，我們就非常注重簡化服務器的構建流程，以便於 LLM 能夠參與進來。 在過去幾年裡，啟動一個 MCP 服務器可能只需要 100 到 200 行代碼，確實非常簡單。 如果沒有現成的 SDK，你也可以將相關的規範或其他 SDK 提供給模型，讓它幫助你構建部分功能。 在喜歡的語言中進行工具調用通常也非常直接。

關於 Google Maps 的例子，我們或許有一定的責任，因為它是我們發布的一個參考服務器。 一般來說，至少目前，對於工具調用的結果，我們有意設計它不一定是結構化的 JSON 數據，也不一定需要匹配特定的模式，而是以文本、圖像這類可以直接輸入 LLM 的消息形式呈現。 也就是說，我們在這方面做了很多努力，旨在讓模型能夠靈活地獲取所需信息，因為這正是它的強項。 我們思考的是如何充分發揮 LLM 的潛力，而不是過度地限製或指定，從而避免隨著模型的改進而變得難以擴展。 因此，在示例服務器中，理想的狀態是所有結果類型都能直接從被調用的 API 原封不動地傳遞過來，由 API 自動傳遞數據。

這裡我可能需要稍微強調一下 AI 在其中的作用。 很多示例服務器是由 Claude 編寫的，這一點並不令人意外。 目前，人們往往習慣於用傳統的軟件工程方法來處理問題，但實際上我們需要重新學習如何為 LLM 構建系統並信任它們的能力。 隨著 LLM 每年都取得顯著的進步，現在將處理數據的任務交給擅長此道的模型是一個明智的選擇。 這意味著我們可能需要放下過去二三十年、甚至四十年的傳統軟件工程實踐經驗。

從另一個角度來看 MCP，AI 的發展速度令人驚嘆，既令人興奮又帶著一絲擔憂。，比如讀取外部數據源、採取 Statefulness 的行動。 在 Anthropic 工作時，我們非常重視安全的交互，並採取了相應的控制和校準措施。 隨著 AI 的發展，人們會期望模型具備這些能力，而將模型與外部連接是提升 AI 生產力的關鍵。 MCP 也正是我們對未來發展方向及其重要性的一種押注。

說得對，我覺得任何帶有「格式化」（formatted）字樣的 API 屬性都應該被移除。 我們應該從所有接口獲取原始數據。 為什麼需要預先格式化呢？ 模型肯定足夠智能，能夠自己對地址等信息進行格式化。 所以這部分應該由終端用戶來決定。

05 怎麼讓 MCP 更好調用更多工具？

坦白說，這個問題沒有一個絕對的答案。 一方面取決於你使用的模型，另一方面取決於工具的命名和描述是否足夠清晰，能夠讓模型準確理解，避免混淆。 理想的狀態是將所有信息提供給 LLM，完全由它來處理一切，這也是 MCP 所設想的未來藍圖。 但在現實應用中，客戶端應用程序（即 AI 應用）可能需要做一些補充工作，比如篩選工具集，或者利用一個小型且快速的 LLM 先篩選出最相關的工具，然後再傳遞給大型模型。 此外，也可以通過將一些 MCP 服務器設置為其他 MCP 服務器的代理來進行篩選。

至少對於 Claude 來說，支持數百個工具是比較穩妥的。 不過對於其他模型的情況，目前還不清楚。 隨著時間的推移，情況應該會越來越好，所以對待限制需要保持謹慎，以免阻礙這種發展。 能夠支持的工具數量在很大程度上取決於描述的重疊程度。 如果服務器的功能各不相同，工具名稱和描述清晰且獨特，那麼能夠支持的工具數量可能就會多於存在相似功能服務器（比如同時連接 GitLab 和 GitHub 服務器）的情況。

此外，這也與 AI 應用的類型有關。 在構建高度智能化的應用時，你可能會減少向用戶提問以及界面的可配置性；但在構建像 IDE 或聊天應用這樣的程序時，允許用戶在不同的時刻選擇他們想要的功能集，而不是始終啟用全部功能，這是完全合理的。

據我所知，順序思維服務器與 Anthropic 的思考工具沒有直接的共同淵源。 但這確實反映了一個普遍現象：為了讓 LLM 進行更周全的思考、減少幻覺或達成其他目標，存在著許多不同的策略，可以從多個維度更全面、更可靠地展現效果。 這正是 MCP 的強大之處——你可以構建不同的服務器，或者在同一個服務器中設置不同的產品或工具來實現多樣化的功能，讓 LLM 應用特定的思維模式來獲得不同的結果。

所以，並不存在一種理想的、規定好的 LLM 思考方式。

沒錯。 我覺得一些 MCP 服務器所採用的方法，恰恰填補了模型在當時自身能力上的空白。 模型訓練、準備和研究需要耗費大量時間，才能逐步提升其能力。 就拿順序思維服務器來說，它看起來可能很簡單，但實際上並非如此，而且它可以在短短幾天內搭建好。 然而，如果想在模型內部直接實現這種複雜的思考功能，那絕不是幾天就能完成的事情。

打個比方，如果我使用的模型不太可靠，或者有人覺得當前模型生成的結果整體上不夠可靠，我可以設想構建一個 MCP 服務器，讓模型針對一個查詢嘗試生成三次結果，然後再從中挑出最佳的一個。 借助 MCP，就能夠實現這種遞歸且可組合的 LLM 交互方式。

06 複雜的 MCP 和 Agent 有什麼區別？

這是一個非常有意思的話題，可以從兩個方面來看。

。 雖然它可能會調用 LLM，但我們希望它能夠保持與具體的模型無關。 這就涉及到了 MCP 的雙向通信功能。 以 Cursor 為例，它管理著與 LLM 的交互循環。 服務器開發者可以通過 Cursor 向客戶端（即用戶所在的應用程序）請求執行某些任務，比如讓客戶端使用用戶當前選擇的模型進行總結，並將結果返回。 這樣，總結模型的選擇就取決於 Cursor，而開發者無需在服務器端引入額外的 SDK 或 API 密鑰，從而實現了與具體模型無關的構建。

。 你可以設想一個 MCP 服務器，它為 Cursor 或 Windsurf 這樣的服務提供支持，同時這個服務器自身也作為一個 MCP 客戶端，調用其他的 MCP 服務器來創造更豐富的體驗。 這體現了一種遞歸特性，在規範的授權等方面也體現了這種模式。 你可以將這些既是服務器又是客戶端的應用程序串聯起來，甚至利用 MCP 服務器構建有 DAG （Directed Acyclic Graph）來實現複雜的交互流程。 智能的 MCP 服務器甚至可以利用整個 MCP 服務器生態系統的能力。 對此，人們已經做過相關的實驗。 如果再考慮到自動選擇、安裝等功能，還有很多可以實現的可能性。

目前，我們的 SDK 還需要添加更多細節，以便開發者能夠更輕鬆地構建既是客戶端又是遞歸 MCP 服務器的應用，或者更方便地複用多個 MCP 服務器的行為。 這些是未來有待完善的內容，但它們已經可以展示一些目前雖然可行但尚未被廣泛採納的應用場景。

我認為通過 MCP 的方式確實可以構建一個 Agent。 這裡需要區分的是，僅僅作為一個 Agent 的 MCP 服務器加上客戶端，與一個真正的 Agent 之間的區別。 例如，在一個 MCP 服務器內部，可以藉助客戶端提供的 sample loop（示例循環）來豐富體驗，並讓模型調用工具，這樣來構建一個真正的 Agent，這種構建方式相對直接。

在 MCP 與 Agent 的關係方面，我們有幾種不同的思考方向：

其一，MCP 可能是一種很好的方式來表達 Agent 的能力，但也許目前還缺少一些能夠提升用戶交互體驗的特性或功能，這些應該被考慮納入到 MCP 協議中。

其二，可以將 MCP 作為構建 Agent，或者讓不同 Agent 之間相互組合的基礎通信層。 當然，也存在其他可能性，比如認為 MCP 更應該專注於 AI 應用層面的集成，而不是過多地關注 Agent 的概念本身。 這仍然是一個正在探討中的問題，每個方向都有其權衡之處。 回到之前關於「萬能盒子」的類比，在設計協議和管理生態系統時，我們需要特別小心的一點是避免功能過於繁雜，不能讓協議試圖包羅萬象，否則可能導致其在各個方面都表現不佳。 關鍵的問題在於，Agent 在多大程度上能夠自然地融入現有的模型和範式框架內，又或者在多大程度上它應該作為一個獨立的實體存在，這仍然是一個尚未完全解決的問題。

我認為，當實現雙向通信，讓客戶端和服務器能夠合二為一，並且可以將工作委託給其他的 MCP 服務器時，它就更像是 Agent 了。 我很欣賞你們始終牢記簡潔性的重要，不試圖解決所有問題。

並不是，幾個月前我們就在 GitHub 上公開討論過 Statefulness 與 Stateless 相關的難題，並一直在權衡。。 這是 MCP 核心團隊內部最具爭議的話題之一，經過了多次討論和迭代。 最終的結論是，因為如果要求 MCP 服務器保持長期持續連接，部署和運營的難度會非常大。 最初的 SSE 傳輸設計，其基本理念是你部署一個 MCP 服務器後，客戶端可以連接進來並保持近乎無限期的連接，這對任何需要進行大規模運營的人來說，都是一個很高的要求，不是一個理想的部署或運營模式。

因此，我們思考如何平衡 Statefulness 的重要性與操作維護的簡便性。 我們推出的可流式傳輸的 HTTP 傳輸方式，包括 SSE，其設計思路是循序漸進的。 服務器可以是一個普通的 HTTP 服務器，通過 HTTP POST 請求獲取結果。 然後可以逐步增強功能，比如支持結果的流式傳輸，甚至允許服務器主動向客戶端發出請求。 只要服務器和客戶端支持 Session Resumption（會話恢復，即可以在斷開連接後重新連接並繼續傳輸），就能夠在兼顧 Statefulness 交互的同時，實現便捷的擴展，並能更好地應對網絡不穩定等狀況。

在協議的下一版修訂草案中，我們已經納入了授權（authentication）規範。 目前主要關注的是用戶到服務器的授權，採用的是 OAuth 2.1 或其現代子集。 這種方式的效果不錯，大家也正在以此為基礎進行構建。 這能夠解決不少問題，因為你肯定不希望用戶隨意粘貼 API 密鑰，特別是考慮到未來大多數服務器會是遠程服務器，它們之間需要進行安全的授權。

在本地環境下，由於授權信息定義在傳輸層，這意味著需要進行數據幀封裝（設置請求頭），而標準的輸入輸出（stdin/stdout）是無法直接實現的。 不過，在本地運行使用標準輸入輸出的程序時，操作非常靈活，甚至可以打開瀏覽器來處理授權流程。

對於授權設計，我認為和協議的其他內容一樣，我們力求相當精簡，解決實際痛點，功能先做到最簡化，再根據實際需求和痛點逐步擴展，避免過度設計。 設計協議需要非常謹慎，因為一旦犯錯，基本上就無法挽回，否則會破壞向後兼容性。 因此，我們只接受或添加那些經過充分考量和驗證的內容，先讓社區通過擴展機制進行臨時嘗試，直到有更廣泛的共識表明某些功能確實應該添加到核心協議中，並且我們有能力在未來持續提供支持，這樣做會更容易、更穩健。

以授權和 API 密鑰為例，我們進行了大量頭腦風暴。 當前的授權方式（OAuth 2.1 子集）已經能夠滿足 API 密鑰的使用場景。 一個 MCP 服務器可以作為 OAuth 授權服務器並添加相關功能，但如果你訪問其「/authorize」網頁，它可能只是提供一個文本框讓你輸入 API 密鑰。 雖然這可能不是最理想的方式，但因為它確實符合現有的模式，並且在當下是可行的。 我們擔心如果添加過多其他選項，客戶端和服務器都需要考慮和實現更多情況，反而增加了複雜性。

我們認識到 Scopes 存在潛在的需求，也進行過討論，但。 我們的標準是，首先要找到當前實現方式無法解決的實際問題，然後在 MCP 結構的可擴展性基礎上進行原型構建，並且證明它能夠帶來良好的用戶體驗後，才會考慮將其正式納入協議。 授權（authentication）的情況有所不同，它更多是從頂層（top-down）設計的。

每次聽到對 Scopes 的描述，我們都覺得很有道理，但我們需要具體的端到端用戶案例來明確當前實現方式的不足之處，這樣才能進一步展開討論。 考慮到可組合性和邏輯分組的設計理念，也有人提出反對意見，不贊成讓單個服務器承擔對多個不同服務的授權任務，認為這些服務本身就應該對應各自獨立的服務器，然後再在應用層面進行組合。

08 MCP 服務器分發的安全問題

關於 MCP 的註冊中心（MCP Registry），目前已經出現了五六個不同的註冊中心，而且官方最初宣布的註冊中心已經停止運營了。 註冊中心的服務模式，如提供下載量、點贊數、評價和信任機制等，很容易讓人聯想到傳統的軟件包倉庫（比如 npm 或 PyPI），但這讓我覺得不太可靠。 因為即使有了社交證明，下一次更新也可能讓一個原本受信賴的軟件包面臨安全威脅。 這種濫用信任系統的情況，感覺就像是建立信任體系反而因為信任系統本身而遭受損害。 因此，我更傾向於鼓勵人們使用 MCP Inspector，因為它只需要查看通信流量，很多安全問題或許就能通過這種方式被發現並解決。 你們如何看待註冊中心的安全問題和供應鏈風險？

沒錯，您說得完全正確。 這確實是所有註冊中心都可能面臨的典型供應鏈安全問題。 針對這個問題，行業內有不同的解決方案。 比如，可以採取類似蘋果 App Store 的模式，對軟件進行嚴格審核，組建自動化系統和人工審核團隊來完成這項工作。 這確實是解決這類問題的一種方法，在某些特定的場景下是可行的。 但我認為在開源生態系統中，這種模式可能不太適用，因為開源生態系統通常採用的是類似 MCP 註冊中心、npm 包管理器和 PyPI（Python 包索引）這樣的去中心化或社區驅動的方式。

這些倉庫本質上都面臨著供應鏈攻擊的問題。 目前已經在官方代碼庫中發布的一些核心服務器，特別是像內存服務器、推理/思考服務器這類比較特殊的服務器。 它們似乎不僅僅是簡單地封裝現有 API，而且使用起來可能比直接操作 API 更便捷。

以內存服務器為例，雖然市場上有一些專注於內存功能的初創公司，但使用這個 MCP 內存服務器，代碼量大約只有 200 行，非常簡單。 當然，如果需要更複雜的擴展，可能需要採用更成熟的方案。 但如果只是想快速引入內存功能，它提供了一個非常好的實現，可能就不需要依賴那些公司的產品了。

其實沒有太多特別的故事。 很多這類服務器都源於我們之前提到的黑客馬拉松。 當時，人們對 MCP 的想法很感興趣，Anthropic 內部一些想要實現內存功能或嘗試相關概念的工程師，就可以藉助 MCP 快速搭建出以往難以實現的原型。 你不再需要成為某個領域的端到端專家，也不需要特定的資源或私有代碼庫，就能為你的應用或服務添加例如內存之類的功能。 很多服務器就是這樣誕生的。 同時，我們在發佈時也在考慮要展示多大範圍的功能可能性。

我完全同意。 我認為這在一定程度上成就了你們發布的成功，。 我還想重點提一下文件系統 MCP 服務器，它提供了編輯文件的功能。 我記得之前在播客中，Eric 曾展示過他出色的 bench 項目，社區對其中開源的文件編輯工具非常感興趣。 市面上有一些相關的庫和方案將這種文件編輯能力視為核心知識產權，而你們直接將這個功能開源出來，這真的非常酷。

文件系統服務器是我個人最喜歡的功能之一。 它解決了我當時遇到的一個實際限制，我有一個業餘的遊戲項目，非常希望能將它與雲服務以及 David 之前提到的「工件（artifacts）」關聯起來。 而能夠讓雲服務與本地機器進行交互，這一點意義非常重大，我非常喜歡這個功能。

這是一個典型的例子，這個服務器的誕生源於我們在創建 MCP 過程中遇到的挫折以及對這種功能的需求。 從遭遇問題，到開發出 MCP 和這個服務器，有著清晰直接的演進脈絡，Justin 對此尤其有感觸。 所以，它在我們心中佔有特殊的地位，可以被視為這個協議的一種精神起源點。

09 MCP 現在已經是多家公司參與的大型項目了

在互聯網上發表意見相對容易，但真正去付諸實踐卻需要付出努力。 我和 Jason 都是傳統的開源理念支持者，我們認為在開源項目中，實際的貢獻至關重要。 如果你通過實際工作，用具體的例子展示了你的成果，並且為你在軟件開發工具包（SDK）中想要的擴展功能投入了精力，那麼你的想法更有可能被項目採納。 如果只是停留在發表意見的層面，你的聲音可能會被忽略。 我們當然重視各種討論，但考慮到有限的時間和精力，我們會優先關注那些投入了更多實際工作的人。

關於 MCP 相關的討論和通知數量非常龐大，我們需要找到更具擴展性的架構來與社區進行互動，從而確保討論是有價值和成效的。 運營一個成功的開源項目，有時需要做出一些可能讓部分人不滿意的艱難決定。 作為項目的維護者和管理者，必須明確項目的實際願景，並堅定地朝著既定的方向推進，即使有人不認同也沒有關係，因為總可能存在更適合他們理念的項目。

以 MCP 為例，它只是解決通用領域相關問題的眾多方案之一。 如果你不認可核心維護者所選擇的方向，開源的優勢就在於你有更多的選擇，你可以選擇「fork」項目。 我們確實期望獲得社區反饋，也努力讓反饋機制更具擴展性，但同時我們也會憑直覺做出我們認為正確的抉擇。 這可能會在開源討論中引發很多爭議，但這有時也是這類開源項目，尤其是在快速發展領域項目的本質所在。

幸運的是，你們對於做出艱難決定似乎並不陌生。 Facebook 的開源項目提供了不少經驗可以藉鑑，即使沒有直接參與，也能了解參與者的做法。 我深度參與了 React 的生態系統，之前成立了一個工作小組，討論過程是公開的。 工作小組的每個成員都有發言權，而且都是有實際工作和重要貢獻的人，這種模式在一段時間內很有幫助。 關於 GraphQL，它的發展軌跡和早期熱度與現在的 MCP 有些相似。 我經歷了 GraphQL 的發展過程，最終 Facebook 將其捐贈給了開源基金會。

這引出了一個問題：MCP 是否也應該這樣做？ 這個問題並非簡單的「是」或「否」，其中存在權衡。

開源領域的治理確實是一個有趣且複雜的問題。 一方面，我們全力致力於將 MCP 打造成一個開放標準、開放協議和開放項目，歡迎所有有興趣的人參與進來。 目前進展順利，例如可流式傳輸 HTTP 的很多想法就來自於 Shopify 等不同的公司，這種跨公司的合作非常有效。 但我們確實擔心官方標準化，尤其是通過傳統的標準化機構或相關流程，在 AI 這樣快速發展的領域，這些流程可能會顯著拖慢項目的發展速度。 因此，我們需要找到一個平衡點：如何在保持現有各方積極參與和貢獻的同時，解決他們在治理模式方面可能存在的顧慮或問題，找到正確的未來方向，而無需經歷反复的組織架構變動。

我們真心希望 MCP 是一個真正的開放項目。 雖然它由 Anthropic 發起，並且我和 David 都在 Anthropic 工作，我們希望各個 AI 實驗室和公司都能參與進來或者利用它。 這非常有挑戰性，需要努力平衡各方利益，避免陷入「委員會決策導致項目停滯」的困境。 開源領域存在多種成功的管理模式，我認為其中大部分微妙之處都圍繞著企業的讚助和企業在決策過程中的話語權。 我們會妥善應對這些相關問題，我們絕對希望 MCP 最終成為一個真正的社區項目。

實際上，目前已經有很多非 Anthropic 的員工擁有 MCP 代碼的提交和管理權限。 例如，Pydantic 團隊對 Python SDK 擁有提交權限；Block 等公司對規範做出了諸多貢獻；Java、C#、Kotlin 等語言的 SDK 分別由 Microsoft、JetBrains、Spring AI 等不同的公司負責完成，並且這些團隊擁有完全的管理權限。 所以，如果你仔細觀察，它實際上已經是一個由多家公司共同參與的大型項目，很多人都在其中貢獻力量，不僅僅是我們兩個人對項目擁有提交權限和相關權利。

我希望看到更多 Support for Sampling 的客戶端。 我也希望有人能構建一些特定的服務器，比如能夠總結 Reddit 討論線程內容的服務器，或者獲取《星戰前夜：晨曦》（EVE Online）上週動態的服務器。 我特別希望前者（採樣客戶端）能夠與模型無關——並不是說我不想用除了 Claude 之外的其他模型（因為目前 Claude 是最好的），而是純粹希望有一個 Support for Sampling 的客戶端框架。

更廣泛地說，如果能有更多支持完整 MCP 規範的客戶端就更好了。 我們在設計時考慮了逐步採用的可能性，如果這些精心設計的基本概念能夠得到廣泛應用，那將非常棒。 回想我最初參與 MCP 工作的動機，以及對文件系統服務器的興奮點——

我在業餘時間是一名遊戲開發者，所以我非常希望能夠看到一個與 Godot 引擎集成的 MCP 客戶端或服務器（我當時就是用 Godot 引擎開發遊戲）。 這樣一來，將 AI 集成到遊戲中就會變得非常輕鬆，或者能夠讓 Claude 來運行和測試我的遊戲。 比如說，讓 Claude 玩《寶可夢》遊戲。 現在已經有實現這個想法的基礎了。 再進一步，從現在開始，讓 Claude 使用 Blender 為你構建 3D 模型，怎麼樣？

坦白說，甚至像著色器代碼（shader code）之類的東西理論上都可以實現。 這確實已經超出了我的專業領域了。 但當你給予開發者們支持和工具後，他們能做到的事情真的非常驚人。 我們正和 David Hersh 一起籌備一場「Claude 玩《寶可夢》」的黑客馬拉松。 本來我並沒有將 MCP 融入其中的計劃，但現在看來或許可以考慮了。