從「接得上」走向「管得住」
MCP（Model Context Protocol）讓 AI Agent 能以一致方式發現並呼叫外部工具。資料庫、企業 API、檔案服務或工作流程，只要包成 MCP Server，就能交給模型操作。這解決了整合介面問題，卻也把另一個問題推到前台：當工具從十幾個增加到數百個，Agent 是否還能快速、正確且安全地選到工具？
來源事實：原始文章指出，生產環境面臨三項相互牽動的難題：企業要暴露哪些能力、Agent 如何找到能力，以及誰有權使用。文章因此主張，MCP 的真正瓶頸不在建立更多 Server，而在工具設計、目錄治理與閘道分區。原文見：https://dev.to/aws-builders/mcp-in-production-tool-design-catalogs-and-the-gateway-problem-1p52
工具過多，消耗的不只是 Token
模型通常要先讀取工具名稱、說明與輸入結構，才知道可以做什麼。若每次請求都載入完整清單，尚未處理使用者問題，工具定義就已占用大量上下文；名稱或參數相似時，也更容易選錯。
Anthropic 的第一方資料提供了具體佐證：一組包含 GitHub、Slack、Sentry、Grafana 與 Splunk 的 58 個工具，定義約占 5.5 萬個 Token；其內部案例曾在最佳化前耗用 13.4 萬個 Token。改採按需搜尋後，該公司測得 Token 用量下降，MCP 評測中的工具選擇準確率也上升。不過，這些是 Anthropic 特定模型、工具集合與內部評測結果，不能直接視為所有系統的普遍效能保證。資料來源：https://www.anthropic.com/engineering/advanced-tool-use
合理推論：工具數量本身不是唯一變數。說明文字長度、名稱相似度、參數複雜度、任務分布與模型能力，都會影響成本與誤選率。因此，「超過 50 個就一定出問題」不應被當成硬性門檻；真正該量測的是每次請求實際載入多少 Token，以及模型能否在相似工具間穩定做出正確選擇。
目錄不是電話簿，而是執行前的控制面
較成熟的做法，是把流程改成「搜尋能力、套用權限、排序候選、只將少量工具交給模型」。此時，目錄不能只有名稱與 JSON Schema，還需要擁有者、版本、狀態、用途、資料分級、可能副作用、所需權限及核准條件。搜尋解決「哪個工具可能適合」，權限過濾則先排除不該被看見或選取的能力。
這也改變工具的產品邏輯。與其提供可任意下 SQL、送 HTTP 請求或執行 Shell 的通用入口，更安全的設計是提供「模擬取消訂單」「提出退款草案」等範圍明確的業務能力。模型只負責選擇意圖；訂單狀態、金額上限、客戶歸屬、冪等性與稽核，仍由既有後端服務以確定性規則驗證。MCP 層應是薄型轉接器，而不是重寫企業核心邏輯的地方。
有 OAuth，不代表這次操作已被允許
MCP 官方授權規格採用 OAuth 2.1 架構，並要求受保護資源的中繼資料與授權伺服器探索；規格也強調最小權限及針對目標資源取得權杖。這能證明身分並建立標準授權流程，但規格本身不會替企業判斷「此員工是否能退款」「這筆金額是否超標」或「此操作是否需要主管同意」。官方規格：https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
本文觀點：權限至少應檢查兩次。第一次在工具被送進模型前，以使用者、Agent、資料等級與信任區域過濾；第二次在實際執行時，再依最新身分、物件狀態與業務政策授權。搜尋排名只是推薦結果，不能被當成授權憑證。
為何需要分區閘道
把數百個工具集中到單一閘道，看似方便，卻同時擴大選擇噪音與攻擊面。較合理的架構是依領域與風險拆分，例如唯讀分析、開發工具、客服作業及高權限生產維運。Agent 若只是查詢成本，就不應看到刪除正式環境資源的工具。分區既是安全邊界，也是提升選擇品質的方法。
另一個值得注意的方向是沙箱程式化呼叫：模型先產生一段受限程式，在沙箱內平行呼叫多個工具、過濾或彙整結果，再把精簡證據送回上下文。Anthropic 展示的案例將工具處理所需 Token 從 15 萬降至 2,000，但同樣只是特定案例。程式執行減少往返與中間資料，不會自動帶來安全；沙箱仍需網路限制、CPU 與記憶體上限、套件管制、短效憑證及完整稽核。來源：https://www.anthropic.com/engineering/code-execution-with-mcp
對台灣企業的實際意義
台灣企業導入 Agent，常會跨越 ERP、CRM、文件平台、製造資料與內部簽核。真正困難的通常不是做出第一個展示，而是釐清每個工具由誰負責、可接觸何種資料、能否寫入，以及版本變更後誰重新驗證。這些工作看似是平台治理，實際上決定 Agent 能否從個人助理升級為可承擔正式流程的企業系統。
容易忽略的是，動態搜尋也可能選錯、目錄可能落後於實際 Server、描述文字可能遭污染，舊版本也可能仍被發現。因此，目錄項目最好綁定實際部署版本、工具結構摘要與核准政策版本；任一項漂移，就暫停被搜尋，直到完成複核。
後續應觀察的指標
- 每次任務載入的工具定義 Token、搜尋步驟增加的延遲，以及端到端成本。
- 正確工具是否進入前幾名候選、相似工具誤選率，以及「不該呼叫工具」時能否停止。
- 未授權工具曝光次數、錯誤副作用、核准被繞過與執行階段拒絕率。
- 目錄與實際部署版本的漂移、失效工具比例、撤銷所需時間及各工具的責任歸屬完整度。
MCP 把工具接入標準化後，競爭焦點將從「誰有最多工具」轉向「誰能讓正確工具在正確權限下被穩定使用」。目錄、閘道、雙重授權與可觀測性不是周邊配備，而是 Agent 真正進入生產環境的基礎設施。