MCP Router：把散落的 MCP Server 收進一個桌面管理器
A Unified MCP Server Management App (MCP Manager).
秒懂
- 它是什麼？
- MCP Router 是一個 Windows 與 macOS 桌面應用，用來集中開關 MCP server、按專案分組、切換 workspace，並透過 @mcp_router/cli 把客戶端接進來。它的價值在於整理，不在於加速；授權條款是 Sustainable Use License 而非標準開源授權，採用前必須先看清楚。
- 適合誰用？
- 如果你同時掛著五個以上的 MCP server、需要在不同客戶端之間共用同一份設定，而且能接受 Sustainable Use License 這種非標準開源授權，MCP Router 值得裝起來試。如果你的團隊要求 OSI 認可的授權、或你只需要在單一客戶端裡設定兩三個 server，直接用客戶端原生的設定檔更省事。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 43 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是設定檔散落，不是效能問題
MCP server 的設定通常寫在各個 AI 客戶端自己的設定檔裡。你用 Claude、Cline、Windsurf、Cursor，就可能有四份清單，同一個 server 被重複定義四次，改一次要改四處。MCP Router 要處理的就是這件事：README 把它定位成「A Unified MCP Server Management App」，在單一 dashboard 上開關 server、逐個工具啟用或停用、把 server 編進 Project 與 Workspace。
目標讀者是同時使用多個 AI 客戶端、而且 MCP server 數量已經多到記不清哪個裝在哪裡的人。單一客戶端、兩三個 server 的使用者不在這個範圍內，他們多裝一層只會多一個要維護的環節。
三層結構：server、Project、Workspace
從 README 的截圖與說明可以看出三層組織方式。最底層是 MCP server 本身，本機或遠端皆可，加入方式支援 DXT、JSON 與手動設定三種。中間層是 Project，把相關的 server 歸在一起，CLI 的 --project 參數就是指向這一層。最上層是 Workspace，README 用瀏覽器設定檔（browser profiles）來類比，意思是同一批 server 可以依情境切成不同組合。
這個類比值得留意。瀏覽器設定檔切換時，分頁與登入狀態是分開的；如果 MCP Router 的 Workspace 也是同樣的隔離語意，那麼「工作用」與「實驗用」的 server 組合可以並存而不互相污染。但 README 只給了類比，沒有說明 Workspace 切換時既有連線是否中斷、憑證是否共用。這部分在文件裡是空白的，採用前應該自己在介面上驗證一次。
工具層級的開關是另一個實際的設計。MCP server 常常一次暴露十幾個 tool，其中真正想讓模型看到的是少數。逐個 tool 停用比整個 server 關掉更細緻，也直接影響送進模型的 context 大小。
CLI 是接入點，憑證是 MCPR_TOKEN
桌面應用本身不直接連客戶端，中間靠 @mcp_router/cli。README 給的流程是先在應用裡新增 custom app 並取得 token，然後在終端機設定環境變數：
export MCPR_TOKEN="mcpr_your_token" npx -y @mcp_router/cli connect
要用特定專案時加上參數：
npx -y @mcp_router/cli connect --project <project-name>
這裡有兩個實務上的細節。第一，token 前綴是 mcpr_，由應用在新增 custom app 時簽發，屬於長期憑證，不是每次連線重新協商。第二，指令用 npx -y 直接抓取並執行，沒有鎖版本，代表每次執行拿到的可能是不一樣的 CLI 版本。在需要可重現性的環境裡，這點要自己想辦法固定。
README 沒有交代 token 的有效期限、撤銷方式，也沒有說明多個客戶端同時用同一組 token 連線會發生什麼。這些都是接入前該在應用介面上確認的。
本機儲存與可稽核性，說得比多數同類專案具體
README 在隱私段落列了三點：請求記錄、設定與 server 資料都存在本機；API key 與驗證憑證同樣存在本機、不往外傳；桌面應用的原始碼公開在 GitHub 上，可以自行檢視驗證。
把「可以自己看程式碼來驗證」寫成隱私主張的一部分，是比較誠實的寫法。多數工具只宣稱資料不外傳，讀者無從查證。這裡至少給了一條查證路徑。
但要注意，這套說法只涵蓋桌面應用。MCP server 本身若是遠端服務，請求內容終究會送到那個遠端端點，本機儲存管不到那一層。README 的措辭是「server data remain on your device」，指的是設定與記錄，不是說遠端 server 的呼叫不會離開你的機器。這兩件事不該混為一談。
授權是 Sustainable Use License，不是 OSI 開源授權
README 的 License 段落寫明採用 Sustainable Use License，並指向 LICENSE.md。儲存庫的授權標示是 NOASSERTION。
這兩件事合起來的意義是：GitHub 無法自動判定授權類別，而 Sustainable Use License 並非 OSI 認可的開源授權。它通常允許內部使用與修改，但對把軟體當成服務轉售或提供給第三方有額外限制。
README 只給了授權名稱與檔案位置，沒有摘要條文。任何要把 MCP Router 包進自家產品、或部署給客戶使用的團隊，都必須直接讀 LICENSE.md 的原文，本文不構成法律意見。純粹在自己機器上管理 MCP server 的個人使用者，這層顧慮通常不存在。
跨平台只有 Windows 與 macOS
README 明列 Cross-platform 為 Windows 與 macOS。Linux 不在其中。
對於在 Linux 工作站或容器裡跑開發環境的團隊，這等於直接排除。CLI 是透過 npx 執行的 Node 套件，理論上不受桌面應用平台限制，但 CLI 要連的對象是桌面應用，應用跑不起來，CLI 也就沒有意義。
另一個限制是架構本身。多一層管理器就多一個必須開著的行程。桌面應用沒啟動、或 token 失效時，所有依賴它的客戶端都會連不上。這是集中管理的必然代價，不是實作缺陷，但排進工作流程前要先想清楚這個單點。
與直接編輯客戶端設定檔的差異
最直接的替代做法，是在每個 AI 客戶端各自的設定檔裡手寫 MCP server 定義。這個做法沒有額外行程、沒有 token、沒有授權問題，改一個 server 就是編輯一個 JSON 區塊。
差別在於狀態的位置。手寫設定檔把狀態分散在各客戶端，好處是每個客戶端獨立、互不影響；壞處是同一件事要在多處重複，而且沒有統一的開關介面，想暫時停用某個 tool 只能去改設定或關掉整個 server。MCP Router 把狀態集中到應用裡，換來的是統一開關、逐 tool 控制與請求記錄，代價是那個應用成為所有客戶端的共同依賴。
選擇的判準很簡單：客戶端數量與 server 數量乘起來，超過你願意手動同步的程度，集中管理就划算；否則多一層只是多一個會壞的地方。
維護節奏與該先驗證的事
從 release 記錄看，v0.6.1 在 2025 年 11 月、v0.6.2 在 2026 年 1 月、v0.6.3 在 2026 年 6 月，儲存庫最後一次推送是 2026 年 8 月。版本號還在 0.6.x，屬於尚未進入 1.0 的階段，介面與 CLI 參數在升級時有變動的可能。
升級成本主要落在兩處：桌面應用要重新下載安裝，CLI 因為用 npx -y 不鎖版本，行為可能隨上游發布而改變。如果團隊需要可重現的環境，應該把 CLI 版本固定下來，而不是每次靠 npx 抓最新版。
在正式導入前，我會先驗證三件事：Workspace 切換時既有連線與憑證的處理方式、MCPR_TOKEN 的撤銷與輪替流程、以及 LICENSE.md 對你們使用情境的實際約束。這三項 README 都沒有給出答案。
編輯結論
如果你同時掛著五個以上的 MCP server、需要在不同客戶端之間共用同一份設定，而且能接受 Sustainable Use License 這種非標準開源授權，MCP Router 值得裝起來試。如果你的團隊要求 OSI 認可的授權、或你只需要在單一客戶端裡設定兩三個 server，直接用客戶端原生的設定檔更省事。動手之前先確認三件事：LICENSE.md 的實際條文、你要用的作業系統是否在 Windows 與 macOS 之外、以及 MCPR_TOKEN 這組憑證在你們的環境裡由誰保管與輪替。
社群筆記