過度承擔的 MCP 職責
一個常見的批評是 MCP 被賦予了過多的責任。 筆者認為，MCP 應該主要作為 LLM 訪問和與外部資源交互的閘道。 將其視為僅僅是一個「門戶」或「橋樑」有助於闡明其目的和局限性。
將意外的數據洩露、提示注入漏洞和成本控制缺陷等問題直接歸咎於 MCP 是錯誤的。 這些問題開發者應該在他們控制的範圍內解決。 開發者需要實施速率限制並監控使用情況，無論使用何種協議。 將這比作指責道路導致超速是很貼切的 —— 基礎設施不對個人行為負責。
歸根結底，許多被提出的擔憂都是與將任務委派給 AI 代理相關的更廣泛問題。 開發者必須負責在他們的特定應用程序中管理這些挑戰，而不是期望 API 本身來處理一切。
LLM 與提示注入的雙面刃
最近圍繞 MCP 的討論常常類似於關於鋒利刀具的內在危險的警告 —— 如果處理不當，它們可能會割傷人。 提示注入是一個重要的擔憂，它是 LLM 本身性質的結果。 試圖消除提示注入風險會降低使 LLM 有價值的那些能力。
在傳統系統中常見的「控制與數據」分離的概念，在 LLM 中並不存在。 LLM 正是因為它們缺乏這種嚴格的分離才獲得了它們的力量和通用性。 這種內在的特性使它們容易受到提示注入攻擊。
雖然遠程 MCP 作為一種服務可能存在風險，但錯誤不在於協議本身，而在於將敏感任務委託給不受信任的第三方。 這種類比延伸到了將刀具用膠帶粘貼到不穩定的 Roomba 上的想法 —— 問題不在於刀具本身，而在於將其附加到不可預測的設備上的決定。
「小心」的告誡或保護裝備的建議，雖然在技術上是準確的，但卻錯過了核心問題：將鋒利的工具與不受控制的系統結合在一起的不明智的決定。
擴展性挑戰
除了安全問題之外，MCP 還面臨著基本的擴展性限制。 筆者強調了 LLM 可靠性與所提供的指令上下文量之間的負相關關係。 這挑戰了這樣一種普遍的觀念，即添加更多的數據和集成將自動解決問題。 隨著工具和集成數量的增加，代理的性能可能會下降，同時增加每個請求的成本。
筆者強調，MCP 無法擴展超過一定的閾值。 試圖向代理的上下文中添加無限數量的工具將不可避免地對其能力產生負面影響。 這種限制是 MCP 概念固有的，需要比身份驗證問題更多的關注。
用戶最終可能會在使用更多 MCP 伺服器時體驗到性能下降，導致它們之間的干擾。 這與典型的包管理系統形成鮮明對比，在典型的包管理系統中，非干擾是一個基本屬性。
MCP 的核心問題是它的實際行為偏離了用戶的期望。 重要的是要認識到，MCP 不是一個即插即用的解決方案，它可以無縫地集成無限數量的工具而沒有任何後果。
使用 UI 和工具管理來解決局限性
一個針對 MCP 限制提出的解決方案是改善使用者介面。 如果一個工具被意外執行，UI 應該提供一個簡單的方式來禁用它或修改其描述以澄清其預期的用法。
筆者還指出，上下文增長通常會導致性能和現實世界使用能力的提高，這與嚴格的負相關概念相矛盾。 然而，他們承認，在某些用例中或使用設計不良的上下文時，可能會發生性能下降。
為了應對工具的過多選擇，建議使用「分而治之」的方法。 這涉及添加一個專門設計的工具，用於選擇給定任務最相關的工具。 這個「工具選擇工具」可能是另一個 LLM 調用，負責返回可用工具的一個子集到「父」代理。 這種分層方法增加了額外的間接層次來管理複雜性。
然而，僅僅在上下文中擁有工具就可以顯著改變模型的輸出。 雖然上下文相關的工具（通過諸如檢索增強生成或 RAG 之類的技術實現）是有益的，但將所有工具隱藏在「get_tools」請求後面可能是有害的。
MCP 作為傳輸和授權層
MCP 主要充當具有請求/響應生命週期的傳輸和線路格式，重點關注工具級別的授權。 這篇文章認為，MCP 的最大問題在於它未能使 AI 代理在功能上組合工具。
筆者認為，MCP 可能根本沒有必要，因為 LLM 已經具備了與使用 OpenAPI 規範記錄的 API 交互的能力。 缺失的元素是授權 —— 控制 AI 可以訪問哪些 API 的能力。 筆者建議，與其使用 MCP，不如允許 AI 發出 HTTP 請求，同時將授權應用於特定的端點。 這種方法與目前使用薄 MCP 工具包裝現有 API 的趨勢相一致。
MCP 一個特別煩人的方面是它缺乏對流式傳輸工具調用結果的支持。 單個請求/響應對迫使客戶端重複調用工具進行分頁，阻礙了長時間運行的過程。 實施流式傳輸能力，或許使用 gRPC，可以顯著提高 MCP 的效率。
暴露敏感數據的便利性
MCP 的一個重要問題是容易暴露敏感數據的潛力。 此外，MCP 本身並不會使 AI 代理更可靠； 它只是授予它們訪問更多工具的權限，這反過來會在某些情況下降低可靠性。
筆者承認他們並不期望 MCP 解決或負責所有這些問題。 相反，MCP 為這些問題創造了一個更大的表面積，要求應用程序開發者和用戶保持警惕。
類比和城市規劃
筆者使用城市規劃的類比來說明這個問題。 將 MCP 比作一條六車道的城市道路，限速為 25 英里/小時，突出了設計與預期用途之間的脫節。 僅僅施加罰款或添加膚淺的「修復」並不能解決不良設計的根本問題。
有效的城市規劃涉及設計能夠自然地鼓勵遵守速度限制的道路。 同樣，MCP 應該被設計成內在地減輕潛在風險，而不是僅僅依賴於外部控制。
LLM 採取不必要的行動
本文轉向對允許 LLM 在服務上執行操作的協議的更廣泛批評。 筆者確定了一個核心問題：LLM 可能會採取用戶不希望它們採取的行動。 他們區分了 LLM 可以獨立採取的行動和那些需要用戶提示的行動。
雖然最終目標可能是讓 LLM 管理整個業務，但該技術尚未準備好實現這種自主性。 目前，用戶甚至可能不希望 AI 在未經事先審查的情況下發送電子郵件。
筆者拒絕了提示用戶進行確認的解決方案，理由是當大多數工具看起來無害時，用戶可能會陷入自動確認的模式（「YOLO 模式」）的風險。 這被比作人們使用卡片比使用現金花費更多的心理現象 —— 這個問題根植於人類行為，而不是技術。
根本問題：為什麼不直接使用 API？
關於 MCP 的討論中一個反覆出現的問題是為什麼不直接使用 API。
MCP 允許用戶不直接控制的 LLM 客戶端（例如，Claude、ChatGPT、Cursor、VSCode）與 API 交互。 如果沒有 MCP，開發者將需要使用 LLM API 构建自定義客戶端，這比使用現有客戶端（帶訂閱）並教他們如何使用特定工具要昂貴得多。
一位開發者分享了他們构建 MCP 伺服器以通過 USB 連接到他們的 FM 硬件合成器的經驗，從而實現了 AI 驅動的聲音設計。
LLM 客戶端集成和標準化
核心問題是並非所有 LLM 客戶端都原生支持直接 API 交互，其中 ChatGPT 自定義 GPT 行為是一個顯著的例外。 Anthropic、Google 和 OpenAI 已同意採用 MCP 作為一種共享協議，以簡化 Claude、ChatGPT 和 Cursor 等 LLM 驅動的客戶端流程。
MCP 簡化了构建 LLM 客戶端的流程。 如果您希望 LLM 與 API 交互，您不能僅僅提供 API 密鑰並期望它工作 —— 您需要創建一個代理。
MCP 可以被視為一種記錄 API 並描述如何調用它們的方式，以及標準化的工具來公開該文檔並促進調用。 它提供了足夠的抽象來包裝 API 而沒有不必要的複雜性，但這種簡單性也可能導致用戶「自掘墳墓」。
MCP 的效率和可重用性
如果沒有 MCP，開發者每次調用工具時都需要重複向 LLM 解釋如何使用工具。 這帶來了 LLM 因為忘記信息或非標準 API 行為而無法正確使用工具的風險。
這種不斷的解釋和重複浪費了上下文中的令牌，增加了成本和時間。 MCP 通過捆綁所有必要的信息來簡化此流程，使工具使用更加高效並促進工具共享。
通過告訴 LLM 提供商「這裡有一個您可以使用的工具」以及 API 文檔，用戶可以在多個聊天中重用該工具，而無需重複提醒。 這也使桌面 LLM 客戶端可以連接到本地運行的程序，解決了操作系統特定的執行過程問題。
MCP 和本地資源訪問
MCP 促進了 LLM 對本地資源（如文件、環境變量和網絡訪問）的訪問。 它被設計為在本地運行，授予 LLM 對這些資源的受控訪問權限。
標準 LLM 工具調用「形狀」與 MCP 工具調用「形狀」非常相似，使其成為將工具連接到代理的簡單標準。
MCP 充當暴露給 AI 模型的函數調用模式和底層 API 之間的橋樑。 它將函數調用轉換為工具，從而實現無縫通信。
如果您是工具提供商，MCP 提供了一種標準化的協議，供 AI 代理前端連接到您的工具。 這回答了為什麼標準協議不能僅僅是 HTTP 和 OpenAPI 的問題。
MCP 是一個元 API，它將端點及其操作細節合併到規範中，使 LLM 能夠更有效地與它們交互。
MCP 在特定場景中的應用
當用戶提出問題或不確定使用哪些 API 時，MCP 可以解決問題。 它還可以根據以前的消息處理請求。
一位用戶分享了他們想要檢索用戶的「X」並將其發送到端點的經驗。 他們發現 MCP 對於如此簡單的任務來說是多餘的，這表明它對於基本的 API 交互來說並非總是必要的。
MCP 被比作一個 FastAPI Web 應用程序框架，用於构建可以通過網絡通信的軟件，專門為代理體驗而設計。 它可以被視為「Rails-for-Skynet」，為 AI 代理開發提供了一個標準化的框架。
關於提供商控制的擔憂
人們擔心 MCP 正在被推動以增加提供商對系統的控制。 LLM 提供商最終可能會限制 API 訪問，類似於 Google 使使用 IMAP/SMTP 與 Gmail 變得困難的方式。
使用 OpenAPI 允許代理從 /openapi.json 檢索 API 規範。
MCP 能夠快速交互，使用戶能夠在幾秒鐘內完成任務，而不是花時間準備輸入數據，將其發送到 API，解析輸出，並為每個消息重複該過程。
沙箱和安全風險
最大的問題之一是一個 MCP 伺服器工具的輸出如何影響同一消息線程中的其他工具。 這需要工具之間的沙箱，以防止意外的後果。 Invariant 實驗室通過工具描述解決了這個問題，而其他人則使用了 MCP 資源附件。 缺乏沙箱加劇了提示注入風險。
這被比作 SQL 注入 —— 一個拼湊在一起的系統，其中漏洞可以在任何點以最小的可觀察性被利用。
提示界面也容易受到一種 SQL 注入的影響，因為模型無法區分提示中值得信賴的部分和用戶污染的輸入。 解決這個問題需要對編碼、解碼和模型訓練進行根本性的改變。
這允許提示注入和工具注入，可能導致執行不可信的代碼。
容器化和受控訪問
一位開發者創建了一個 MCP 伺服器，該伺服器啟動一個掛載了項目代碼的 Docker 容器。 這種方法允許 LLM 在沙箱環境中訪問整個 Unix 工具集和項目特定的工具。
這種通過基於聊天的界面驅動的代理工作流程，已被證明比傳統方法更有效。
關鍵是授予 MCP 代理他們需要的訪問權限，而不是更多。 容器化和透明的工具 UX 對於減輕安全風險至關重要。
虛擬機和互聯網訪問
給予代理一台具有最小 Linux 安裝的計算機（作為 VM 或容器）可以產生更好的結果，允許他們從互聯網獲取信息。 然而，這引發了關於惡意指令和數據洩露的安全問題。
限制對可信網站的訪問可以減輕一些風險，但即使是可信來源也可能託管惡意內容。 必須仔細權衡遇到惡意指令的可能性和生產力收益之間的權衡。
員工和 AI 代理之間的差異很大。 員工是受法律和合同約束的法人，提供問責制。 AI 代理缺乏這種法律框架，使得信任更加困難。
MCP 開發的早期階段
MCP 僅在 2024 年 11 月宣布，並且 RFC 正在積極發展中。
一些人認為整個 AI 個人助理概念，包括 MCP，從根本上存在缺陷。
在 1990 年代末和 2000 年代初對 AI 助理的最初推動失敗了，因為具有垂直整合和批量購買力的內容聚合器被證明更有效。 這導致了 Expedia 和 eBay 等平台的崛起。
多代理系統要求程序員影響代理的狀態，這是一項具有挑戰性的編程任務。
免費價值的限制
想要「按停車位可用性對結果進行排名」突出了訪問付費 API 或廣告支持的前端背後數據的問題。 公司不太可能通過 API 免費提供對其整個數據集的訪問權限。
雖然並非所有公司都會將其數據集成到 AI 代理中，但組合各種工具來推動工作流程的潛力仍然很大。
優先保持數據護城河的公司可能會抵制威脅該護城河的新技術。
如果 booking.com 有一個 API，他們可能會返回與他們的網站相同的結果，可能使用 JSON 或 XML 格式。
繞過中間人
booking.com 這樣的中間人允許用戶完全繞過他們的服務是沒有意義的。
然而，個別酒店可能會發現繞過 booking.com（他們經常不喜歡的中間人）是有益的。
一個深度研究 AI 可以根據特定標準掃描酒店，並與個別酒店運營的酒店發現 MCP 伺服器交互，而無需導航 booking.com 的界面和廣告。
實際用例
MCP 可以促進從 Elasticsearch 獲取日誌或以更結構化的方式查詢數據庫等任務。
MCP 伺服器配置的靜態性質（其中新伺服器需要編輯 .json 文件並重新啟動應用程序）可能具有局限性。
微調模型
MCP 可以被視為一個小的、微調的模型，它理解眾多的 MCP 工具，並為每次對話選擇正確的工具。
根據上下文動態調整工具對於某些場景可能是必要的。
開放式對話和業務問題
MCP 非常適合沒有預定義流程的通用、開放式對話系統。 然而，它並不是每個業務問題的一刀切解決方案。 它無意取代 LangChain 等框架。
MCP 的替代方案，一個開放的社區驅動的標準，是分散的、專有的和供應商鎖定的協議。 一個有缺陷但不斷發展的標準比沒有標準更好。
查看 MCP 的最佳方式是從個別開發者构建 API 的客戶端包裝器轉變為 API 提供商或社區維護的包裝器构建它們。 這提供了一個大型工具箱，類似於 NPM 或 PyPi。 然而，仍然需要協調、安全和用法定義。
下一代 Langchains 將受益於這個更大的工具箱，但仍然需要創新。
用戶特定工具
在某些情況下，工具可能是用戶數據特定的，例如用於切片和操作上傳的 CSV 文件的工具。
一個經常被忽視的問題是 MCP 會用過多的選項擠滿模型上下文。 優先級排序和元數據暴露對於避免浪費令牌使用和不穩定的模型行為至關重要。
標準和不斷發展的技術
新的標準會隨著時間的推移而出現，而且距離標準真正重要已經過去了很長時間，以至於人們已經忘記了它們是如何發展的。
從隨機開發者那裡下載小型伺服器程序以將「工具」添加到 LLM 客戶端可能存在風險。
提出的問題是 MCP 生態系統需要解決的合法問題。 一些解決方案將在 MCP 規範中，而另一些解決方案將在外部。
Claude 代碼和實際使用
對於 MCP 的成功存在相反的意見。 一些人聽說過公司與 MCP 集成的故事，而另一些人則聽說過用戶發現它令人失望。
這突出了炒作和早期採用的缺點。
一些開發者發現 HTTP API 在大多數用例中優於 MCP。 他們認為「工具」的使用歸結為能力的 API 端點和功能。
API 默認情況下不是自描述的，這代表了 REST 和 HATEOAS 支持者展示他們方法的機會。
MCP 作為 LangChain 的替代方案？
MCP 被描述為具有「LangChain 氣味」 —— 沒有解決緊迫的問題，過於抽象，並且難以解釋其優勢。
也許它需要說「END OF LINE」並將wannabe 駭客驅逐到遊戲網格！
一個關鍵問題是「通用」聊天機器人範式是否會持續存在。 具有自己工具的專業應用程序可能不需要 MCP。
相反，隨著 LLM 變得越來越有能力，外部工具可能變得越來越不必要。 當 LLM 可以直接編輯圖像時，為什麼您需要 MCP 來驅動 Photoshop？
科幻機器人助理的夢想可能不會實現，而專業的語言操作工具可能更有用。
用戶群體和安全意識
MCP 的用戶群體包括不太懂技術的個人，使得安全問題尤其重要。 提高對安全最佳實踐的認識至關重要。
基於 OpenRPC 的 Xops 需要定義結果模式，有助於計劃輸出如何連接到輸入，從而提高複雜工作流程的可靠性。
該技術可能會隨著時間的推移而發展並穩定下來。
冗餘和雲基礎設施
一些人質疑使用 MCP 而不是 OpenAPI 標準的收益，認為它是多餘的。
LLM 將使用什麼來調用 OpenAPI 系統？ 它將如何綁定到 shell？ LLM 的主機將如何協調？
MCP 提供了一種結構化的方式供 LLM 進行工具調用。
MCP 伺服器已經是 HTTP 伺服器。
MCP 最大的優勢在於 OpenAI 等 LLM 提供商，而不是應用程序開發者。
LLM 是沒有工具的大腦，而工具調用賦予了它們能力。 然而，使用普通 API，LLM 提供商無法訪問這些工具。 MCP 授予他們訪問權限，將他們定位為 AI 的閘道。
CLI vs. API
既然 LLM 接受過自然語言訓練，並且 CLI 是一種常見的人類可讀寫的解決方案，為什麼不直接使用 CLI？
MCP 出現得太快，需要時間才能成熟。 它缺乏傳統標準機構的審查，並且受到炒作的驅動。
缺乏實際應用。
MCP 的關鍵應用
MCP 用於 Claude Desktop 和利基 AI 聊天應用程序、代碼自動化工具和代理/LLM 自動化框架。
這是另一項倉促的技術，當下一個可炒作的縮略語出現時，很可能會被丟棄。
有兩種類型的語言模型工具調用協議：人們抱怨的協議和沒人使用的協議。
Anthropic 在真空中開發了這個「標準」，導致了安全問題。
JSON-RPC 2.0
MCP 基於 JSON-RPC 2.0 构建，這是一種輕量級協議，允許客戶端和伺服器使用 JSON 進行通信。
它感覺像是一個為特定生態系統設計的集中式規範，聲稱具有普遍性但沒有獲得它。
MCP 足夠強大，可以做有用的事情，這引發了安全問題。
它不是一個成熟的標準，也不是為了安全而設計的。
雖然存在建議，但它們沒有被強制執行或實施。
Langchain 和工具調用
Langchain 是實現「工具調用」模式的眾多框架之一。
MCP 是一個規範，說明外部信息如何進入語言模型的上下文窗口，包括工具調用、模板化輸入、取消、進度跟踪和工具伺服器的狀態。
它有助於標準化細節，因此任何助理/集成組合都是兼容的。
雖然 MCP 存在合理的問題，但批評者應該完善他們的論點。
身份驗證至關重要，不應從初始版本中省略。
存在太多的複雜性。