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 工程師

TLDR:

• 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 的理念和實際操作的復雜性之間找到平衡。

Founder Park 正在搭建開發者社群，邀請積極嘗試、測試新模型、新技術的開發者、創業者們加入，請掃碼詳細填寫你的產品/項目信息，通過審核后工作人員會拉你入群～

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

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

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

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

01

MCP 是如何誕生的？

swyx（主持人）：首先，MCP 是什么？

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

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

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

swyx（主持人）：客戶端和服務器的特性意味著它是雙向，就像 USB-C 接口一樣，這很有意思。很多人嘗試做相關研究、構建開源項目。我感覺 Anthropic 在爭取開發者方面，比其他實驗室都積極。好奇這背后是受外部影響，還是你們倆在某個房間里靈光一現想出來的？

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

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

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

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

Alessio（主持人）：時間線是怎樣的呢？我知道 11 月 25 日是正式發布日期。你們什么時候開始著手做這個項目的？

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

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

swyx（主持人）：回到構建 MCP，我們看到的只是最終成果，它明顯受 LSP 啟發，這點你們倆也承認。想問問構建時的工作量如何？構建過程主要是大量編寫代碼，還是做大量設計工作？我感覺設計工作占比大，比如選用 JSON-RPC，借鑒 LSP 的程度如何？還有哪些部分難度較大 ？

Justin：我們從 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 之類的并不重要，而將重點放在基本元素等創新上，這些方面借鑒前人成果對我們很有幫助 。

swyx（主持人）：我對協議設計感興趣，這里有很多內容能展開。你們已經提到 M x N Problem，其實從事開發者工具工作的人都遇到過，也就是 「萬能盒子（Universal Box）」 問題。

基礎設施工程的基本問題和解決辦法是，要將很多東西連接到 N 個不同事物，弄個 「萬能盒子」 就好。像優步、GraphQL、我曾工作的 Temporal 以及 React 都有這類問題。好奇你們在臉書時有沒有解決過 N 乘以 N 的問題？

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

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

02

MCP 的核心概念：

工具、資源與提示缺一不可

swyx（主持人）：看 MCP 文檔時我就有這個疑問，為什么這兩個東西要有區別呢？很多人將工具調用當成萬能解法，實際上不同類型的工具調用意義不同，有時是資源，有時是執行操作，有時是其他用途。我想了解你們將哪些概念歸為相近類別？為什么強調它們的重要？

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

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

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

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

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

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

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

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

Alessio（主持人）：拿著錘子，就想把所有東西都當成釘子，用工具調用解決一切問題。比如很多人用它進行數據庫查詢，而不是資源調用。我好奇在有API接口（如數據庫）的情況下，使用工具和資源各有哪些優缺點？什么時候該用工具做 SQL 查詢？什么時候該用資源處理數據？

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

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

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

swyx（主持人）： 是的，我在 Claude Desktop 中看到@符號時，立刻想到了這和 Cursor 的功能是一樣的，現在其他用戶也可以利用這個功能了。這個設計目標很棒，因為功能本身已經存在，人們可以很容易地理解并使用。我展示了那張圖表，你們肯定也認同它的價值，我認為它非常有幫助，應該放在文檔首頁，這是一個很好的建議。

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

swyx（主持人）：好的，我去提交。

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

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

swyx（主持人）：我覺得這正是資源和工具概念存在一定融合的地方，因為你現在提到有時需要一定程度的用戶控制或應用程序控制，而在其他時候又希望由模型來控制。所以，現在我們是否只是在選擇工具的一個子集？

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

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

03

MCP 與 OpenAPI：

競爭還是互補？

swyx（主持人）：想談談 MCP 與開放API（Open API）的對比，畢竟這顯然是大家非常關注的問題之一。

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

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

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

Alessio（主持人）： 我在 AGI 工作室聯合主持了一場黑客馬拉松。作為個人 Agent 開發者，我看到有人構建了一個能夠生成 MCP 服務器的個人 Agent：只需要輸入API規范的 URL，它就可以生成對應的 MCP 服務器。你們如何看待這種現象？是不是意味著大多數 MCP 服務器僅僅是在現有 API 之上增加了一個層，而沒有太多獨特的設計？未來會一直是這樣，主要依靠AI來對接已有的 API，還是會出現全新的、前所未有的 MCP 體驗？

Justin/David：我認為這兩種情況都會存在。一方面，「通過連接器將數據引入應用程序」這類需求始終是有價值的。盡管目前更多的是默認使用工具調用，但未來其他的基本概念或許更適合解決這類問題。即使它仍然是一個連接器或適配器層，通過適配不同的概念也能增加其價值。

另一方面，確實有機會出現一些有趣的應用場景，構建不僅僅充當適配器的 MCP 服務器。例如，一個內存 MCP 服務器可以讓 LLM 在不同的對話中記住信息；一個順序思維 MCP 服務器可以提升模型的推理能力。這些服務器并非與外部系統集成，而是為模型提供全新的思考方式。

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

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

04

怎么快速構建 MCP 服務器：

用 AI 編程

Alessio（主持人）： 我覺得 MCP 還有一個方面人們討論得相對較少，那就是服務器的構建。對于那些想要開始構建 MCP 服務器的開發者，你們有什么建議嗎？作為服務器開發者，如何在提供詳細描述（讓模型理解）與直接獲取原始數據（留給模型后續自動處理）之間找到一個最佳平衡點？

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

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

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

Alessio（主持人）：我發現，服務器構建者在很大程度上決定了最終返回的數據格式和內容。比如在工具調用的例子中，像 Google Maps，返回哪些屬性是由構建者決定的。如果缺少某種屬性，用戶就無法覆蓋或修改它。這和我對一些 SDK 的不滿之處類似：當人們構建API封裝的 SDK 時，如果他們遺漏了 API 新增的參數，我就無法使用這些新功能。你們如何看待這個問題？用戶應該擁有多大的干預能力，還是完全由服務器設計者來決定？

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

Alessio（主持人）： 在哪里劃定這個界限確實是一個很難做出的決定。

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

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

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

05

怎么讓 MCP 更好調用更多工具？

swyx（主持人）： 我還想問一個問題，一個 MCP 實現能夠支持多少個相關功能？這涉及到廣度與深度的問題，也與我們剛才討論的 MCP 嵌套直接相關。

2024 年 4 月 Claude 推出首個百萬 token 上下文示例時，曾表示能夠支持 250 個工具，但在很多實際情況下，模型并不能真正有效地使用這么多工具。從某種意義上說，這是一個廣度問題，因為沒有工具調用工具的情況，只有模型和一層平鋪的工具層級結構，這樣很容易出現工具混淆。當工具的功能相似時，模型就可能調用錯誤的工具，導致結果不理想。對于在任何特定時間啟用的 MCP 服務器的最大數量，你們有什么建議嗎？

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

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

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

swyx（主持人）：最后，我們重點談談順序思維服務器（Sequential Thinking MCP Server）。它具備分支功能，還能提供「更多編寫空間」的能力，這些都非常有趣。另外，Anthropic 上周發布了一篇新的工程博客，介紹了他們的思考工具（Thinking Tool），社區對于順序思維服務器和這個思考工具之間是否存在重疊產生了一些疑惑。實際上，這只是不同團隊以不同的方式在做類似的事情，畢竟實現方法多種多樣。

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

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

swyx（主持人）： 我認為不同的應用會有不同的用途，而 MCP 正是允許你實現這種多樣化，對嗎？

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

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

06

復雜的 MCP 和 Agent 有什么區別？

Alessio（主持人）： 我接下來想問關于可組合性的問題。你們怎么看待將一個 MCP 引入另一個 MCP 的概念？對此有什么相關計劃嗎？比如，如果我想構建一個用于總結 Reddit 版塊內容的 MCP，這可能需要調用一個對應 RedditAPI的 MCP，以及一個提供總結功能的 MCP。那么，我該如何構建這樣一個「超級 MCP」呢？

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

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

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

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

swyx（主持人）： 這聽起來非常令人興奮，我相信很多人會從中獲得很多想法和靈感。那么，這種既是服務器又是客戶端的 MCP，可以算作是一種 Agent 嗎？從某種程度上說，Agent 是你發出一個請求，它會去執行一些你可能不完全清楚的底層操作。在你和最終的原始數據來源之間存在一層抽象。你們對于 Agent 有什么獨到的見解嗎？

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

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

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

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

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

07MCP下一步：如何讓協議更可靠？

swyx（主持人）：近期關于從有狀態服務器到無狀態服務器的更新引起了大家的興趣。你們選擇服務器發送事件（SSE）作為發布協議和傳輸方式，并且支持 pluggable（可插拔，指更具靈活性）的傳輸層，這背后的原因是什么？是受到了Jared Palmer推文的影響，還是早已在籌備之中？

Justin/David：并不是，幾個月前我們就在 GitHub 上公開討論過 Statefulness 與 Stateless 相關的難題，并一直在權衡。我們認為AI應用、生態系統和 Agent 的未來發展方向傾向于 Statefulness。這是 MCP 核心團隊內部最具爭議的話題之一，經過了多次討論和迭代。最終的結論是，盡管我們看好 Statefulness 的未來，但不能因此背離現有的范式，必須在 Statefulness 的理念和實際操作的復雜性之間找到平衡。因為如果要求 MCP 服務器保持長期持續連接，部署和運營的難度會非常大。最初的 SSE 傳輸設計，其基本理念是你部署一個 MCP 服務器后，客戶端可以連接進來并保持近乎無限期的連接，這對任何需要進行大規模運營的人來說，都是一個很高的要求，不是一個理想的部署或運營模式。

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

Alessio（主持人）：是的，還包括會話 ID。關于未來的身份驗證，你們有什么計劃嗎？目前，對于一些 MCP，我只需要在命令行中粘貼我的API密鑰。你們認為未來的發展方向是什么？會不會有類似于 MCP 專屬的配置文件之類的東西來管理認證信息？

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

在本地環境下，由于授權信息定義在傳輸層，這意味著需要進行數據幀封裝（設置請求頭），而標準的輸入輸出（stdin/stdout）是無法直接實現的。不過，在本地運行使用標準輸入輸出的程序時，操作非常靈活，甚至可以打開瀏覽器來處理授權流程。關于在本地是否使用 HTTP 進行授權，我們內部目前尚未完全確定，賈斯汀傾向于支持，而我個人不太贊同，存在爭議。

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

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

Alessio（主持人）： 你們有沒有考慮過 scopes（作用域）的概念？昨天我們和 Agent.ai 的創建人Dharmesh Shah做了一期節目。他舉了一個關于電子郵件的例子：他擁有自己所有的電子郵件，希望能有更細粒度的 Scopes 控制，比如「你只能訪問這些類型的郵件」，或者「只能訪問發給這個人的郵件」。如今，大多數作用域通常是基于 RESTAPI設計的，即你能訪問哪些特定的端點。你們認為未來模型有可能理解并利用 Scopes 層，從而動態地限制傳輸的數據嗎？

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

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

08

MCP 服務器分發的安全問題

Alessio（主持人）： 我認為 MCP 一個很出色的設計是它的編程語言無關性。據我了解，Anthropic 沒有官方的 Ruby SDK，OpenAI 也沒有。盡管像 Alex Rudall 這樣的開發者在構建這些工具包方面表現出色，但有了 MCP，我們不再需要為各種編程語言分別適配 SDK，只需要創建一個被 Anthropic 認可的標準接口就可以了，這一點非常棒。

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

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

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

以內存服務器為例，雖然市場上有一些專注于內存功能的初創公司，但使用這個 MCP 內存服務器，代碼量大約只有 200 行，非常簡單。當然，如果需要更復雜的擴展，可能需要采用更成熟的方案。但如果只是想快速引入內存功能，它提供了一個非常好的實現，可能就不需要依賴那些公司的產品了。對于這些非API封裝型的特殊服務器，你們有沒有什么特別的故事可以分享？

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

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

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

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

09

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

swyx（主持人）： 關于 MCP 的討論非常熱烈。如果人們想參與這些辯論和討論，應該通過什么渠道呢？是直接在規范的代碼庫討論頁面上嗎？

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

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

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

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

這引出了一個問題：MCP 是否也應該這樣做？這個問題并非簡單的「是」或「否」，其中存在權衡。目前大多數人對 Anthropic 在 MCP 上的工作是滿意的，畢竟是你們創造并管理著它。但當項目發展到一定規模時，可能會遇到瓶頸，意識到這是一個由公司主導的項目。人們最終會期望真正的開放標準由非營利組織來推動，具備多方利益相關者和良好的治理流程，例如由 Linux 基金會或 Apache 基金會管理的那些項目。我知道現在討論這個問題可能為時尚早，但想聽聽你們對此的看法？

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

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

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

Alessio（主持人）： 對于未來的 MCP 服務器或客戶端，你們有什么特別的「愿望清單」嗎？有沒有哪些你們特別希望人們能夠構建，但目前還沒有實現的功能？

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

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

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

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