為每個代理提供單一端點，而非每個儲存庫 20 份 MCP 設定。

背景

該平台團隊為分布於十餘個產品小組中的約六十名工程師提供支援。在採用 MCP 的一年間，各小組各自將所需的伺服器——GitHub、Postgres、Linear、Sentry，以及一款內部部署工具——直接接入 Claude Code 與 Cursor 的設定之中。每個儲存庫皆攜帶各自的 mcp.json，而引入一款新工具則意味著須向每一個需要它的專案提交拉取請求。

此種做法尚可運作，卻難以擴展。二十餘個伺服器如今於數十份設定檔中重複出現，各自版本略有差異，憑證則由最初完成設定者隨手貼入其中。

挑戰

以下三個問題於回顧會議中反覆出現。

• 設定蔓延。 新增或升級一個伺服器都須改動每個儲存庫。設定逐漸漂移，無人能確切說清哪個小組擁有哪些工具。
• 憑證所在失當。 個人存取權杖與 API 金鑰散落於開發者機器之上，偶爾更會進入已提交的設定。輪換一枚外洩的權杖宛如大海撈針。
• 擁擠的情境視窗。 每個 MCP 伺服器都會於每次請求時將其完整的工具結構描述推入提示。在接入二十個伺服器的情形下，代理在看到實際任務的第一行之前，便已將大量情境耗費於工具定義。

方法

該團隊搭建了單一的 onemcp 入口，將其伺服器一次性納入其中，並就地對每個上游完成鑑權。各用戶端不再各自與每個伺服器通訊，而是統一與入口通訊，再由入口向各上游分發。

有兩點改變了問題的形態：

• 以單一端點取代眾多端點。 儲存庫不再羅列伺服器，而是將 Claude Code 或 Cursor 指向入口 URL，即可繼承整套經過甄選的工具。更換或升級伺服器僅需於入口中執行一次。
• 以 Code Mode 取代成堆的定義。 入口不再預先注入每一份工具結構描述，而是僅公開三個中繼工具——search、describe 與 execute。代理自行發現某項任務所需的少數工具，並於一次往返中透過單個指令碼予以呼叫。

落地

遷移歷時兩週，逐個小組推進。對每個儲存庫，團隊刪除其本地伺服器清單，並置入單一入口條目。由於憑證已由入口保管，開發者於此過程中亦將權杖從各自機器上一併移除。

平台團隊將入口作為唯一的管控點：新伺服器經集中審核後加入，存取權限亦於同一處管理，而非散布於數十份 mcp.json 之中。

結果

• 20 餘個伺服器匯於單一端點之後。 各儲存庫引用同一個入口 URL。新增一款工具是一次入口變更，而非一次波及全體儲存庫的拉取請求。
• 每次請求的工具開銷降低約 90%。 以三個中繼工具取代數百份預載定義，使每次請求的工具開銷從約 15,000 個權杖降至約 500 個——代理得以將這部分情境用於任務本身。
• 憑證移至伺服器端。 上游 OAuth 與權杖駐留於入口之內，絕不進入用戶端設定或已提交檔案。輪換只需於一處完成一次更新。

我們不再於拉取請求中提交 MCP 設定。如今儲存庫只需指向一個端點即可取得全部工具，權杖亦由安全團隊而非我們掌管。

相關案例研究

• 某 AI 客服代理的權杖瘦身
• 在不外洩憑證的前提下實現自助式資料代理