Google Cloud API Gateway 支援將 REST API 轉為 MCP 工具

Google Cloud API Gateway 原生支援 MCP 協議

Google Cloud API Gateway 現已進入公開預覽階段，可將現有 REST API 轉換為 Model Context Protocol (MCP) 工具。企業內部有大量能力被鎖在 REST API 後面，AI Agent 無法直接存取，這項更新就是要處理這個問題。過去，開發團隊若要讓現有 API 能被 Agent 呼叫，通常得建立並維護一個獨立的 MCP 伺服器，重新實作路由、驗證與配額邏輯，不僅增加營運負擔，也和閘道器既有的處理機制重複。現在，開發者只要在已部署的 OpenAPI 規格中加入特定註解，就能把 REST 操作直接暴露成 Agent 可用的 MCP 工具，不必另外建置中介軟體或基礎設施。

技術實作與 OpenAPI 註解

API Gateway 是 Google Cloud 閘道器產品線中的輕量級入口，適合需要快速保護、管理並暴露 Cloud Run 服務 API 的場景。若需要完整的企業級 API 生命週期管理、進階流量策略或貨幣化，建議使用 Apigee；若要治理 Agent 的出站呼叫，則可搭配 Agent Gateway。技術上，API Gateway 接受標準的 MCP JSON-RPC 請求，並轉譯成對應的 REST 請求。轉譯後的請求與一般 REST 呼叫無異，因此開發者現有的 JWT 或 API Key 驗證、配額限制及日誌政策都能直接套用，MCP 與 REST 流量走同一條政策路徑，也共用相同的配額分配。

要啟用這項功能，開發者必須使用 OpenAPI 3.0.x 或 3.1.x 規格；目前不支援 OpenAPI 2.0，需先遷移。在文件層級，透過 `x-google-api-management.mcp` 選擇啟用，設為 `true` 或使用物件形式（例如設定 tools-list 的安全性）都會全域啟用 MCP。針對個別操作，可透過 `x-google-mcp-tool` 自訂工具名稱與描述。每個暴露的操作都必須指定後端（backend），且描述不能為空。例如在訂單服務中，可以把 `getOrderStatus` 操作標記為 `get_order_status` 工具，並寫上詳細的使用情境描述，因為大型語言模型主要是依據工具描述來決定要不要呼叫該工具。

部署流程與安全性設定

部署流程與一般 API 配置相同。API Gateway 會自動產生支援 MCP 的配置，並在 `/mcp` 基礎路徑上提供服務，不需額外配置基礎設施。安全性方面，`tools/list` 方法預設不需驗證，方便開發測試，但工具名稱和輸入模式會對所有查詢者公開。正式環境建議要求 JWT 驗證，要注意的是 API Key 無法用來保護這個方法。不論是否保護探索功能，`tools/call` 一律會強制執行底層 REST 操作所需的驗證機制。

開發者可以把任何 MCP 客戶端指向閘道器的 `/mcp` 端點。以 Google ADK 為例，只要提供閘道器 URL 與所需憑證（如 API Key），就能建立 Agent 並綁定工具。閘道器會把工具參數對應到 REST 的路徑、查詢、主體和標頭，執行請求並套用現有政策，最後把後端回應當作 MCP 結果回傳。用 `curl` 等工具可以直接看到 JSON-RPC 請求與回應的結構，確認工具呼叫是否正確轉譯。

可發現性與當前限制

這項功能的一大優點是可發現性。將閘道器連接到 API Hub 後，其 MCP 伺服器會發布到 API Hub 並附上 MCP 特定中繼資料，同時自動出現在 Agent Registry，讓開發者和 Agent 能輕易找到暴露的工具。由於沿用現有的規格、閘道器、驗證、配額和日誌系統，做到了「無需操作新事物」，MCP 與 REST 流量也能保持一致。

目前公開預覽版涵蓋 REST 和 OpenAPI 3.x 後端，並使用現有的驗證機制。未來規劃包含 MCP 資源、提示、回應串流及 Model Armor 負載檢查等功能。不過目前仍有幾項限制：回傳空主體（如 HTTP 204）的操作不會被暴露；深度巢狀的物件模式在 `tools/list` 中可能無法完整呈現；單一閘道器最多支援 1,000 個工具；同一個 API 配置中，也無法同時啟用 MCP 和模型路由（Model Routing）。開發者可參考官方文件取得最新的支援範圍，並立即開始把 API 轉換為 Agent 可用的工具。