Bốn ngày. Đó là thời gian một bạn engineer trong team mình bỏ ra quý trước để viết một service Python có mỗi một việc: dịch REST call thành MCP tool call, để agent xử lý ticket support có thể tra trạng thái đơn hàng. Bốn ngày công, thêm một service mới vào lịch on-call, thêm một bản sao logic auth phải giữ đồng bộ với API gốc. Google vừa làm cái service đó trở nên thừa thãi — nếu bạn đang dùng API Gateway.

Ngày 24/9, Google Cloud ra mắt tính năng hỗ trợ MCP cho API Gateway ở Public Preview. Ý tưởng: gắn annotation vào OpenAPI spec bạn đã có sẵn, deploy lại, và gateway sẽ nói được MCP JSON-RPC tại một endpoint duy nhất /mcp — tự transcode mỗi tools/call thành REST request phía sau, rồi dịch response ngược lại. Không cần server riêng. Không cần bản auth thứ hai để rồi lệch pha với bản gốc.

Annotation trông như thế nào

Có hai cấp bật tính năng. Ở cấp document, để bật MCP cho cả spec:

x-google-api-management:
  mcp: true
  backends:
    orders-backend:
      address: https://orders-a1b2c3-uc.a.run.app

Và ở cấp từng operation, để mô tả tool mà agent sẽ nhìn thấy:

paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      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."

Vậy thôi. Không có deployment target mới, không base image mới, không secret mới phải xoay vòng. Spec bắt buộc phải là OpenAPI 3.0.x hoặc 3.1.x — nếu chỗ nào bạn còn dùng 2.0, việc migrate giờ trở thành điều kiện bắt buộc để agent truy cập được, chứ không còn là “làm sau cũng được”.

Phần đáng để tâm nhất: auth không đổi

JWT hay API key check, quota bucket, và logging bạn đã cấu hình cho REST operation đó áp dụng nguyên vẹn cho MCP call. Một operation, một quota allocation, bất kể protocol nào gọi tới. Đây mới là cái thắng thật sự — không phải “agent gọi được API của bạn” (cái đó thì wrapper viết tay nào cũng làm được), mà là “agent thừa hưởng đúng những rào chắn mà REST client của bạn đang sống dưới đó, không phải duy trì hai bộ policy song song”.

Nhưng có một điểm sắc cần chú ý: tools/list — lệnh discovery mà agent dùng để xem có những gì khả dụng — mặc định không yêu cầu xác thực. API key không khóa được nó; bạn cần JWT, khai báo tường minh:

x-google-api-management:
  mcp:
    tools-list:
      security:
        orderServiceJwt: []

Nếu bỏ qua bước này, bất kỳ agent nào tìm ra endpoint /mcp của bạn cũng liệt kê được toàn bộ operation bạn đã annotate trước khi cần bất kỳ credential nào. tools/call vẫn buộc phải qua đúng auth mà REST operation gốc yêu cầu — nên không có gì được thực thi mà thiếu xác thực — nhưng bề mặt API của bạn thì ai hỏi cũng thấy. Hãy coi nó như một route /api/docs không xác thực: có ngữ cảnh thì ổn, có ngữ cảnh thì là một finding thật sự trong security review.

Chỗ hết dễ chịu

Đây là Public Preview, và giới hạn của nó cụ thể đến mức sẽ có người dính trong vòng một tháng sau khi launch. Một gateway giới hạn tối đa 1.000 tool. Những operation trả về body rỗng — kiểu 204 No Content quen thuộc — không được lộ ra chút nào, nghĩa là bất kỳ REST API nào thiết kế theo kiểu “thành công là body rỗng” đều cần nghĩ lại trước khi giao operation đó cho agent. Response streaming chưa hỗ trợ. MCP resources và prompts — phần của spec nằm ngoài tool-calling — cũng chưa. Và bạn không thể bật MCP cùng lúc với model routing trong cùng một API config, nên nếu định kết hợp cái này với routing dựa trên Gemini trong cùng một gateway, bạn phải chọn một trong hai.

Dòng chữ giờ quan trọng hơn cả tài liệu API

Đây mới là thay đổi thật sự với các team API: trường description trong x-google-mcp-tool không còn là tài liệu tham khảo nữa. Nó là tín hiệu duy nhất mà LLM có để quyết định tool của bạn có phải cái cần gọi cho một yêu cầu cụ thể hay không. Chính hướng dẫn của Google cũng nói thẳng — viết rõ khi nào và tại sao dùng tool này, đừng chỉ mô tả nó trả về cái gì.

Phần lớn description REST mình từng review suốt mười lăm năm qua đọc kiểu “Trả về trạng thái đơn hàng theo ID.” Câu đó ổn với một người đang lướt trang docs, đã biết mình cần tra trạng thái đơn hàng. Nhưng là một câu tệ cho một LLM đang phân vân, giữa bốn mươi tool, xem đây có phải cái trả lời được câu “đơn hàng của tôi đang ở đâu” hay không. Viết lại description theo kiểu câu ý định — “dùng tool này khi người dùng hỏi đơn hàng đang ở đâu hoặc khi nào tới” — chỉ mất năm phút mỗi endpoint, và đó chính là phần việc thật sự mà tính năng này tạo ra cho bạn. Cứ dự trù thời gian cho nó, vì không ai đưa nó vào sprint plan đâu nếu bạn không chủ động.

Chỗ nào nên dùng, chỗ nào chưa cần

Nếu bạn đang dùng Apigee để quản lý toàn bộ vòng đời API, hoặc Kong, hoặc gateway tự viết, tính năng này chưa ảnh hưởng gì đến bạn cả — API Gateway là tầng nhẹ, còn MCP-như-một-tính-năng-nền-tảng chắc sẽ dần xuất hiện ở các sản phẩm cao cấp hơn của Google theo thời gian. Nhưng nếu bạn đang ngồi trên một mớ REST API sau API Gateway thuần và quý này bị giao nhiệm vụ “cho agent gọi được cái này”, bỏ luôn ý định viết wrapper service. Gắn annotation vào spec, khóa tools/list lại, viết lại description cho tử tế, và dùng bốn ngày tiết kiệm được để review xem một agent thật sự nên được phép làm gì với một POST một khi nó đã chạm tới được.