代理框架與安全
實測 1,723 個 MCP 應用：近三分之二未在工具執行前要求批准
首個大規模 MCP 用戶端研究發現，官方 SDK 與檔案式設定已成主流，但阻塞式工具批准率僅 37.2%。協定統一了通訊格式，卻尚未讓權限、設定與人工監督形成一致的應用層慣例。
一項 7 月 28 日公開的實證研究，從 GitHub 蒐集 1,723 個整合 Model Context Protocol（MCP）的應用，檢查開發者如何設定伺服器、選用 SDK，以及在人與代理之間安排控制點。結果顯示，81.1% 使用官方 SDK、85.2% 以檔案保存伺服器設定，代表 MCP 的基本整合路徑已開始收斂；但設定檔名稱仍未形成共同慣例，增加自動探索、移植與安全稽核的難度。
更值得注意的是監督機制的不對稱：90.8% 的應用會留下日誌，77.2% 允許啟用或停用伺服器，卻只有 37.2% 在工具真正執行前加入阻塞式批准。換言之，多數應用雖能事後追蹤，也能一次關閉整組工具，但模型通常可以在工具已啟用時直接呼叫。對具備檔案寫入、命令執行或外部 API 權限的代理而言，這三種控制並不等價；日誌無法撤回已送出的資料，伺服器級開關也難以限制單次高風險參數。
官方 MCP 規格主要定義 JSON-RPC 訊息、生命週期、授權，以及伺服器提供的 tools、resources、prompts 等能力，並未替應用規定統一的批准介面或設定格式。研究因此建議把用戶端慣例也視為標準化問題。工程團隊可先為工具建立逐項風險等級，將寫入、付款、刪除及憑證操作設為同步批准，並把呼叫參數與結果納入可遮蔽的稽核紀錄。
這些數字不能直接代表整個 MCP 生態：樣本只來自公開 GitHub 儲存庫，分類流程亦使用 LLM 輔助，私有企業應用可能採用不同控制。接下來應觀察新版無狀態傳輸與 SDK 更新是否帶來可攜式權限政策，以及阻塞批准是否真正驗證參數，而非只顯示籠統的工具名稱。