MCP

MCP Gateway 使用前指南：將多個 MCP 伺服器與 REST API 聚合為固定工具表面（非商業授權）

最適合被多個 MCP 伺服器和 REST API 的工具定義撐滿上下文的情境：單一 Rust 執行檔把所有後端聚合為 14 到 16 個固定元工具，用 gateway_search_tools 搜尋、gateway_invoke 呼叫；使用前最重要的前提是預設授權僅涵蓋個人與非商業用途，商業執行需要商業授權。

官方來源 · GitHub - MikkoParkkola/mcp-gateway

安裝

brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run

如果你把多個 MCP 伺服器和 REST API 接進同一個 AI 用戶端，很快就會發現工具定義本身就把上下文撐滿了。MCP Gateway 的做法是在用戶端與所有工具之間放一個單一 Rust 執行檔：各種後端都掛在它後面，agent 看到的是 14 到 16 個工具的緊湊元表面，而不是每個後端的完整定義。上下文裡的工具定義越多，留給真正任務的預算就越少；把它收斂成一個固定的小表面，正是它要解決的問題。動手前先確認一個前提：它預設採用非商業授權，個人與非商業用途（包括執行完整閘道）免費，商業執行需要商業授權。

適合誰

  • 適合已經接入或計畫接入多個 MCP 伺服器與 REST API、希望工具清單體積保持穩定的使用者：不管後面掛多少後端，agent 面對的都是固定的一小組元工具，而不是所有後端定義的總和。
  • 適合能在本機常駐執行一個服務的人：閘道以本機 HTTP 服務方式執行，用戶端透過本機端點連上它。
  • 不適合在商業環境直接使用：商業執行需要商業授權，這是採用前必須解決的前提；只有少量通用建構塊組成的 MIT 核心以 MIT 授權開放。
  • 只有少量後端、工具清單本來就不長時，聚合的價值有限；小規模情境下的具體效益，證據未提供對比數據。
  • 支援的用戶端名單、遠端部署與身分驗證方式，證據未提供，屬於未確認項目，請勿自行假設。

3 分鐘完成第一次嘗試

  • 前提：一個可用 Homebrew 的環境。官方提供的安裝入口是 Homebrew tap，其他安裝方式證據未提供。
  • 依序執行官方主路徑的三條命令：
brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run
  • 第二步的 setup wizard 會匯入你現有的伺服器並把用戶端接上。注意這是本機狀態寫入：它會改寫閘道與用戶端的本機設定，不是唯讀操作；實際寫入哪些檔案、如何保存，證據未逐項說明。
  • 第三步啟動後，閘道作為本機 HTTP 服務執行。用戶端側依官方提供的設定片段連接。片段把名為 gateway 的服務宣告為 http 類型，指向本機 39400 連接埠的 /mcp 路徑：
{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}
  • 成功訊號：用戶端連上 http://localhost:39400/mcp 後，工具清單收斂為固定的一小組；此時呼叫一次 gateway_search_tools，官方描述它用於搜尋後端工具——如果搜尋能返回你已接入後端的工具，表示用戶端到閘道的鏈路已經打通。證據未標註該工具的 readOnlyHint，其唯讀屬性未確認；第一次嘗試只做搜尋，不執行寫入類動作。這時 agent 載入的是固定的一小組元工具，而不是全部後端定義。

使用案例

  • 案例一：為多伺服器工具堆疊瘦身。情境：用戶端已接多個 MCP 伺服器，每個後端的工具定義都在消耗上下文。做法：把現有伺服器交給精靈匯入，用戶端只保留 http://localhost:39400/mcp 這一個端點。預期：agent 的工具表面固定在 14 到 16 個左右，而不是所有後端定義的總和；需要某個具體能力時，先用 gateway_search_tools 搜尋定位。判斷依據：用戶端呈現的工具數量是否明顯少於你接入後端的工具總數。
  • 案例二：搜尋後呼叫一次真實工具。情境：想執行某個已連接後端（MCP 伺服器或 REST API）提供的能力。做法：先用 gateway_search_tools 定位目標工具，再用 gateway_invoke 呼叫它，官方描述的用法正是搜尋加呼叫這兩個元工具。預期：呼叫被轉發到對應後端並返回其結果；具體輸出取決於你接入了什麼後端，證據中沒有固定範例輸出。如果搜尋不到預期工具，先確認該後端是否已透過精靈匯入，再重試搜尋。

使用邊界

  • 授權與限制：個人與非商業用途免費，包括執行完整閘道；商業執行需要商業授權；僅少量通用建構塊的 MIT 核心以 MIT 開放。這一條決定能不能用、在什麼範圍用，放在所有判斷之前。
  • 讀寫性質與副作用：閘道本身是本機常駐服務；精靈會寫本機設定；gateway_invoke 會實際驅動後端工具，副作用取決於所呼叫的那個後端，執行前先確認目標操作的性質與確認點。
  • 依賴：安裝依賴 Homebrew；接入現有伺服器透過精靈匯入完成。
  • 未確認項目：支援的用戶端名單、REST API 的具體接入設定格式、localhost 之外的部署方式、身分驗證機制，以及各元工具是否標註 readOnlyHint，證據中均未說明。閘道本身是否有存取控制、日誌如何記錄，證據同樣未說明。找不到說明不代表沒有風險，採用前請以官方儲存庫目前文件為準。