Google API Gateway 加一段註解，現有 REST API 就變成 MCP 工具

Google Cloud API Gateway 現在可以直接當遠端 MCP 伺服器。做法是在既有的 OpenAPI 3.x 規格裡加註解，Gateway 就會把 Agent 送來的 MCP JSON-RPC 請求轉成一般 REST 呼叫，後端完全不用動。驗證、配額、日誌也沿用 Gateway 上原本的設定，不用另外架中介層。 技術上的分工很乾淨。MCP 負責「Agent 怎麼發現工具、參數長什麼樣」，REST 後端負責「事情怎麼做」。以前想讓 Agent 呼叫公司內部 API，得自己寫一個 MCP server，包一層、處理 auth、再顧 rate limit。現在這層被 Gateway 吸收，而 OpenAPI 本來就是機器可讀的說明書，直接拿來當 tool schema。就像舊房子不拆，只在牆上多裝一個轉接插座。 同一天 AWS 推出 Lambda Web Functions，Express、Next.js 這類標準 HTTP 應用可以直接跑在 Lambda 上，不必改寫成 event handler。兩件事方向一致：雲端廠商在拿掉「改寫成本」，讓既有程式碼原封不動接上新的執行模式或新的呼叫者。 但有幾個坑。REST API 當初是給前端工程師寫的，端點粒度和錯誤訊息從沒考慮過 LLM 怎麼讀。一百個端點全轉成工具丟給 Agent，工具太多模型會選錯，描述寫太爛它會亂填參數。轉換是免費的，工具設計不是。權限也一樣：Agent 沿用現有驗證，它能碰的範圍就等於那組憑證的範圍。 缺口也在往下游移。同天 Google 開源 AQuA，專門診斷 Agent 上線後的品質退化；Hacker News 上的 Sphinx 則在部署前抽問開發者，看他懂不懂自己推的 AI 程式碼。接上去已經不難，難的是接上去之後誰盯著。 我猜接下來拉開差距的，不是誰的 API 能變成 MCP，而是誰挑得出那十個該被暴露的。