Google Cloud API Gateway เปลี่ยน REST API เป็น MCP tools ได้ด้วยการเพิ่ม annotation ใน OpenAPI ไม่ต้องสร้าง MCP server เอง แต่ tools/list เปิดสาธารณะเป็นค่าเริ่มต้น

Google ประกาศบน Developers Blog เมื่อ 24 ก.ย. 2026 ว่า Cloud API Gateway ทำหน้าที่เป็น remote MCP server ได้แล้ว ในสถานะ Public Preview วิธีใช้คือเพิ่ม annotation ลงใน OpenAPI spec ที่ deploy อยู่แล้ว แล้ว deploy ใหม่ จากนั้น REST operation เดิมจะกลายเป็น MCP tool ที่ agent เรียกได้ทันที โดยไม่ต้องสร้าง โฮสต์ หรือดูแล MCP server แยก

ปัญหาที่ Google ต้องการแก้คือ ถ้าทีมอยากให้ agent เรียก REST API ภายในองค์กรได้ ทุกวันนี้มักต้องตั้ง MCP server แยกขึ้นมาอีกตัว แล้วเขียน routing, authentication และ quota ใหม่ ทั้งที่ gateway ทำเรื่องเหล่านี้อยู่แล้ว ฟีเจอร์นี้ออกมาบนผลิตภัณฑ์เดียวกับ model routing ที่เราเขียนถึงเมื่อ 5 ส.ค. ซึ่ง Google เรียกว่า “companion capability” ที่ดูแลทราฟฟิกฝั่งขาออกไปหา LLM ส่วนความสามารถใหม่นี้ดูแลฝั่งที่ agent เรียกเข้ามา

ทำงานอย่างไร

gateway รับ MCP JSON-RPC ที่ endpoint เดียว แปลง tools/call แต่ละครั้งเป็น REST request ที่ตรงกัน ส่งผ่าน policy ที่ตั้งไว้ แล้วแปลง response กลับเป็นผลลัพธ์แบบ MCP เนื่องจาก request ที่แปลงแล้วหน้าตาเหมือน REST call ปกติทุกอย่าง JWT หรือ API key, quota และ logging เดิมจึงใช้ได้ต่อโดยไม่ต้องแก้ และ operation หนึ่งตัวใช้ quota ก้อนเดียวกันไม่ว่าจะถูกเรียกผ่าน REST หรือ MCP

ขั้นตอนมีดังนี้

1. ใช้ OpenAPI 3.0.x หรือ 3.1.x เพราะ OpenAPI 2.0 ใช้ไม่ได้ gateway ที่ยังใช้ spec 2.0 ต้อง migrate ก่อน
2. เปิด MCP ที่ระดับเอกสาร ด้วย x-google-api-management.mcp แล้วใช้ x-google-mcp-tool เพื่อตั้งชื่อ แก้คำอธิบาย หรือข้าม operation ที่ไม่ต้องการเปิด operation ที่จะเปิดเป็น tool ต้องมี backend และ description ที่ไม่ว่าง
3. deploy ตามปกติ แล้ว gateway จะให้บริการ MCP ที่ base path /mcp

ตัวอย่างจากบล็อกของ Google (ตัดมาบางส่วน):

x-google-api-management:
  mcp: true                 # expose this spec's operations as MCP tools
  backends:
    orders-backend:
      address: https://orders-a1b2c3-uc.a.run.app
paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      description: Returns the current status, carrier, and ETA for an order.
      x-google-backend: orders-backend
      x-google-mcp-tool:
        name: get_order_status
        description: "Look up the delivery status and ETA of a customer order.
          Use this when the user asks where an order is or when it will arrive."

Google แนะนำว่าคำอธิบาย tool ควรบอกว่า ควรเรียกเมื่อไรและเพราะอะไร ไม่ใช่บอกแค่ว่าคืนค่าอะไร เพราะ LLM ใช้คำอธิบายนี้เป็นสัญญาณหลักในการเลือก tool ฝั่ง client ใช้ MCP client ตัวไหนก็ได้ ตัวอย่างในบล็อกใช้ McpToolset ของ ADK ต่อผ่าน StreamableHTTPConnectionParams ถ้าเชื่อม gateway กับ API hub ไว้ MCP server จะถูกเผยแพร่ใน API hub และปรากฏใน Agent Registry ให้อัตโนมัติ

จุดที่ต้องระวังก่อนนำขึ้น production

• tools/list ไม่ต้องยืนยันตัวตนเป็นค่าเริ่มต้น บล็อกเตือนว่าค่านี้ “publishes your tool names and input schemas to anyone who asks” ถ้าจะใช้ใน production ต้องบังคับใช้ JWT และบล็อกย้ำว่า “API keys cannot secure this method” ส่วน tools/call ยังบังคับ auth ตามที่ REST operation นั้นกำหนดไว้เสมอ
• ข้อจำกัดใน Preview: gateway หนึ่งตัวมีได้สูงสุด 1,000 tools, operation ที่คืน body ว่าง เช่น HTTP 204 จะไม่ถูกเปิดเป็น tool, schema ที่ซ้อนกันลึกอาจแสดงใน tools/list ไม่ครบ และ เปิด MCP กับ model routing พร้อมกันใน API config เดียวกันไม่ได้
• ข้อจำกัดที่อยู่ในเอกสาร แต่บล็อกไม่ได้พูดถึง: ไม่รองรับ stdio transport, ไม่รองรับ JSON-RPC batch, response เป็นข้อความ UTF-8 เท่านั้น (ส่ง binary ไม่ได้), ทำงานแบบ stateless (ไม่ใช้ MCP-Session-Id), ไม่จัดการ CORS preflight ที่ /mcp ให้ และ ไม่ใส่ tool annotation อย่าง destructiveHint หรือ readOnlyHint ส่วน method อื่นนอกจาก initialize และ tools จะได้ error -32601
• roadmap: MCP resources และ prompts, response streaming และการตรวจ payload ด้วย Model Armor

มุมมอง AI Curator

ข่าวนี้ทำให้ MCP เป็นแค่อีกรูปแบบหนึ่งที่ API gateway เปิดให้บริการ เหมือนที่ gRPC-JSON transcoding เคยทำกับ gRPC จุดที่มีประโยชน์จริงคือ MCP กับ REST ใช้ policy ชุดเดียวกัน ทีมที่มี API หลายสิบตัวบน Cloud Run อยู่แล้วจะไม่ต้องดูแล MCP server อีกหลายตัวที่ auth ไม่ตรงกับ gateway สำหรับทีมในไทยและ SEA ที่ใช้ Google Cloud อยู่แล้ว นี่เป็นทางที่ง่ายที่สุดทางหนึ่งในการเปิด API ภายในให้ agent บน Gemini Enterprise หรือ ADK เรียกใช้

แต่มีกับดักที่ต้องระวังสองข้อ ข้อแรกคือ tools/list เปิดสาธารณะเป็นค่าเริ่มต้น ทีมที่ใช้ API key อย่างเดียว ซึ่งเป็นเรื่องปกติมากในบริษัทไทยขนาดกลาง จะปิดส่วนนี้ด้วย key ไม่ได้ ถ้าไม่ตั้ง JWT ใครก็ดูรายชื่อและ schema ของ API ภายในได้ ซึ่งเป็นข้อมูลที่ช่วยคนร้ายสำรวจระบบได้มาก ข้อที่สองคือ ไม่มี readOnlyHint หรือ destructiveHint แปลว่า MCP client จะแยกไม่ได้ว่า tool ไหนแค่อ่านข้อมูลและ tool ไหนลบข้อมูล ถ้าคุณ annotate ทั้ง spec ที่มี DELETE อยู่ agent ก็จะเรียก DELETE ได้เหมือน GET แนวทางที่ปลอดภัยกว่าคือเปิดเฉพาะ operation ที่อ่านข้อมูลก่อน แล้วค่อยเพิ่มทีละตัว

ในระยะยาว การที่ Google แบ่งเป็นสามชั้น คือ API Gateway สำหรับเริ่มต้นแบบเบา Apigee สำหรับองค์กร และ Agent Gateway สำหรับควบคุมทราฟฟิกขาออก บอกว่า MCP กำลังกลายเป็นฟีเจอร์พื้นฐานของ API management เหมือน OAuth ในยุคก่อน ทีม platform ควรเริ่มถือว่า OpenAPI spec เป็นทั้งเอกสารสำหรับนักพัฒนาและเมนูเครื่องมือสำหรับ agent ไปพร้อมกัน และเขียน description ให้ LLM อ่านเข้าใจได้ด้วย

แหล่งข่าว

• Turn your REST APIs into MCP tools with Google Cloud API Gateway — Google Developers Blog (24 ก.ย. 2026)
• Model Context Protocol overview — API Gateway Docs
• OpenAPI 3.x feature limitations (MCP limitations) — API Gateway Docs